Computers in Industry 53 (2004) 133152

A UML model of agile production planning and control system

Tunglun Tsaia, Ryo Satob,*
a

Graduate School of Policy and Planning Sciences, University of Tsukuba, Tsukuba, Japan
Institute of Policy and Planning Sciences, University of Tsukuba, Tennodai 1-1-1, Tsukuba, Ibaraki, Japan
Received 26 June 2002; received in revised form 23 July 2003; accepted 23 July 2003

Abstract
Agile production planning and control system (APPCS) is a system for planning, scheduling, procurement, and production
control. APPCS plays an important role in the competitive environments, such as make-to-order industries, because it excels in
immediate uncertainty processing and then guarantees feasibility of the production plan. The uncertainty is often caused by
customers who make a change in the order or by suppliers who change their promised items. The customers or suppliers can
notify of the change before it really happens. Upon receipt of the change, APPCS responds immediately to achieve higher
service level of performance, better resource utilization, and less material loss.
This paper provides a UML model of APPCS. The proposed model concretely defines the APPCS and makes the immediate
planning and scheduling possible. In order to testify the model, both instance of the model and its implementation in a simulator
are shown.
# 2003 Elsevier B.V. All rights reserved.
Keywords: Agile production planning and control system; UML; Planning and scheduling; Production control; Uncertainty

1. Introduction
This paper provides a universal modeling language
(UML) description of the agile production planning
and control system (APPCS). APPCS, proposed by
Sato and Tsai [9], is an integrated system of material
requirement planning, job oriented scheduling, procurement, and production control for uncertainty processing on a basis of inventory, released purchased
orders, and work-in-process (WIP).
The APPCS has the following characters [9]. (1) A
set of demands from master production scheduling
(MPS), inventory, purchased orders, and WIP are
*

Corresponding author. Tel.: 81-298-53-5543;

fax: 81-298-55-3849.
E-mail address: rsato@shako.sk.tsukuba.ac.jp (R. Sato).

inputs of the system. (2) An advanced production

system (APS) is adopted to produce a feasible production plan. (3) When customers change their request,
and/or suppliers cannot maintain start time planned
supply, with respect to date or quantity, they give
advance notification before the change really happens.
Upon arrival of such information, APPCS makes
immediate update of the production plan by APS.
APSs are proposed as an enhancement to enterprise
resource planning (ERP) systems that rely on MRP
logic [5]. APS schedules backward from due date of a
demand by netting out quantity of inventory, released
purchased orders, and WIP recursively from finished
product to raw material. At the same time it reserves
capacity of resources for the net requirement to determine the latest possible start time for the demand.
If the start time is in the past, then APS schedules

0166-3615/$ see front matter # 2003 Elsevier B.V. All rights reserved.
doi:10.1016/j.compind.2003.07.003

134

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

forward from a start time, usually the present time, to

get the earliest possible finish time. A feasible production plan is thus generated.
Planning, scheduling and control are fundamental
business processes and the hierarchical nature of them
follows the natural flow of decisions in an organization
[4]. To integrate these business processes, a job plays
an important role in carrying data among these processes. A job is generated as net requirements of
finished product, assembly, or raw material in the
planning process, the scheduling process determines
its start time and finish time, and it serves as a base unit
of production control.
The sequence of demands executing planning and
scheduling are determined by the earliest due date
(EDD) rule. A demand is planned to be a set of jobs by
referencing bill of materials recursively. The job of
production is transformed into a set of schedules by
job oriented scheduling. Job oriented scheduling
schedules one job at a time, so that all the operations
of a job are scheduled before the next job is considered [7]. APPCS adopts job oriented scheduling in
order to work well with the finite-capacity scheduling.
A purchase order is generated for a job or jobs that
request the same raw material according to various
rules.
During production control, a job of production will
be released to the shop floor by distributing the
schedules to the related work centers. A job of procurement starts when the generated purchase order is
released to a vender. Gantt chart provides the
resources with graphic understanding of the assigned
schedules. A resource processes the operation at the
specified work center by following the distributed
schedules.
Uncertainty becomes inevitable in modern times.
We can view it as an important message from the
changing market. Sanchez and Nagi [6] regards a
planning, scheduling, and control system that is able
to reschedule or recover from many uncertainties of
the market as a further research of agile manufacturing
system. Tu [13] gave a problem domain to production
planning and control in a virtual one-of-a-kind production (OKP) company under uncertainty. Real-time
monitoring of production progress, a control structure
that can be flexibly extended to cope with the uncertainties, and an adaptive production scheduling algorithms are included in the problem domain. A flexible

structure of production control accompanies with the

capability of immediate rescheduling is very important to handle the uncertainties.
The proposed APPCS model is equipped with the
rescheduling capability based on a job-based structure. An uncertainty can cause some jobs to be unattainable. In APPCS, the invalid jobs and their
schedules are first cancelled, and then planning and
scheduling runs again to generate another feasible
production plan. Silver et al. [5] indicated that the
frequent updates from the planning process lead to a
poor communication between the planning department and the shop floor. To avoid such a dispute,
the jobs that have been released to the shop floor are
not cancelled, and the in-processing jobs become
constraints for the subsequent planning and scheduling process.
A data model for product data management and
planning is available in [2]. This paper showed an
augmentation so that APPCS is possible. The formulation of APPCS is described by the UML and illustrated by class diagram, state chart diagram, and
sequence diagram. The UML is a language for specifying, visualizing, constructing, and documenting
the artifacts of software system, as well as for business
modeling and other non-software systems [8]. It is
composed of foundation, behavioral elements, and
model management packages. A package is a grouping of model elements. The foundation package
defines the constructs to abstract a static model.
System requirements of the APPCS are specified in
Section 2 and they act as guidelines of system analysis
and design in Section 3. The system requirements are
compiled and abstracted by following the UML foundation package. All the technical terms used in this
paper follow OMG unified modeling language specification. In Section 4, we provide an example of the
APPCS model to demonstrate how the APPCS is
applied. Finally, a conclusion is provided in Section 5.

2. System requirements of the APPCS

2.1. Production data
Customers request finished products. A finished
product is made by assembling necessary assemblies
and raw materials. In turn, putting together other

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

135

Fig. 1. A product structure diagram of bicycle.

assemblies and raw materials makes an assembly.

Finally raw materials are procured externally from
venders. A vertical relationship with a required quantity stems from a finished product or an assembly to its
input assemblies or raw materials is called bill of
materials, in short BOM.
Fig. 1 is an example of BOM. In the figure, a
rectangle is a finished product, an assembly, or a
raw material, a solid line with a number denotes the
required quantity between two rectangles, an arrow
dotted line expresses the procurement, and an arrow
solid line indicates the demand. There are seven BOM
in the product structure designed for bicycle, tire set,
brake set, derailleur set, body, control system, and
frame, respectively.
To make a finished product or an assembly, some
necessary manufacturing steps are performed. Each
step is called an operation and the set of operations
forms a routing. A routing is specified for each BOM
of finished product or assembly. The raw materials and
other assemblies specified in a BOM are input to the
operations during manufacturing. An operation for a

part is specified by a setup time, a unit processing time

and a manufacturing work center for scheduling. A
routing of the assemblytire set is listed in Fig. 2.
A work center is a category of resources that have
capability to process some operations. Assembly
lines, polishing shops, and brushing machines are
examples of respective work centers. A resource is
either a labor or a machine. A work center can enroll
numbers of resources, and a resource can join more
than one work center if necessary. The capacity of a
resource is finite and managed by shifts. A shift
defines the workable time on the planning horizon.
The planning horizon indicates a time axis toward the
future for which production planning is made. By
assuming finite loading, the planning and scheduling
process reserves the capacity of resource only inside
its shifts.
2.2. Planning and scheduling
Planning and scheduling is a process that transforms independent requirements of a finished product

Fig. 2. A routing of tire.

136

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

with due date to executable manufacturing schedules

and procurement requirements of raw materials. Forecasting and customer orders are sources of the independent requirement. A demand is used to represent a
quantity of independent requirement that requests a
finished product before a due date. It acts as a base unit
of the planning and scheduling process. Demands
trigger planning and scheduling according to priority.
The EDD rule grants the highest priority to the
demand with the EDD.
Planning and scheduling of a demand begins by
calculating net requirement of its finished product.
The net requirement is a deduction of available inventory on hand, quantity of released purchase order, and
WIP from the independent requirements. If the finished product is procured externally, then the net
requirement is scheduled to be released no later than
procurement lead time before the due date. Otherwise,
it is manufactured internally and a set of operations
must be specified. For each operation, necessary processing time is scheduled to be provided by a resource
of the specified work center.
The net requirement of a finished product is
regarded as a job to be accomplished. If a job is
manufactured internally, then it is a manufacturing
job, otherwise it is a procurement job. Fig. 3a shows a
job i of net requirement 10 is planned by deducting
five units of inventory, 10 units of released order, and
five units of WIP from 10 units of independent
requirement and 20 units of dependent requirement.
After the job i is planned, it is turned out that its net
requirement should be followed by dependent requirements of the next planning jobs, n and m. Fig. 3b
shows a result of scheduling of the manufacturing job i

before epoch 84. That is the earliest start epoch among

the various requirements. The schedules are shown in
the form of Gantt chart, in which a bar without oblique
lines is a schedule.
To start a manufacturing job, a certain quantity of
input assemblies and/or raw materials must be supplied. The quantity is a dependent requirement, and it
is a multiplication of the unit quantity specified in the
BOM with net requirement of the job. A set of jobs is
created for the dependent requirements. A dependent
requirement of job m (10) and that of job n (20) are
shown in Fig. 3a. They must be provided to job i no
later than epoch 30. Such process continues until all
the propagated jobs finish planning and scheduling.
In this manner, a demand triggers planning and
scheduling in a top-down sequence of jobs backwardly
from demands due date to get a latest start time is
called backward scheduling. If the start time fell into
the past, then the result of backward scheduling is
infeasible, and forward scheduling approach is introduced to schedule the jobs in a bottom-up sequence
from the present time to get an earliest finish time.
2.3. Procurement
After all the demands were planned and scheduled,
a set of procurement jobs is generated. They are
supplied by releasing purchase orders. If the lot-forlot (L4L) policy is adopted, a purchase order, or we say
supply from the viewpoint of a vender, is generated for
each procurement job. Besides the L4L, economic
order quantity (EOQ) and periodic order quantity
(POQ) rules are usually used. The EOQ is to minimize
the ordering cost and the inventory carrying cost by

Fig. 3. Planning and scheduling of a job.

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

assuming a constant demanding rate in the periodic

basis. However, Vollman et al. [12] pointed out EOQ
results in a mismatch between supply quantities and
actual request quantities in the case of MRP.
An improvement of EOQ is POQ that applies EOQ
and the demanding rate in computing an economic
time between orders (TBO). The jobs for the same raw
materials within the TBO are aggregated to form a
purchase order. Requested quantity of the purchase
order is the summation of their net requirements, and
release time and arrival time are arranged to the start
time and finish time of the earliest job among the jobs.
2.4. Production control
The production control by APPCS is to monitor the
execution of released jobs and their schedules. Uncertainty is unpredictable event that could make the
production plan invalid. A demand change caused
by a customer or forecasting error, and supply change
caused by a vender are such uncertainty. If the production system does not learn to deal with it, it is prone
to cause the production system an inconceivable loss.
Whybark and Williams [3] pointed out sources of
uncertainty are: (1) supply timing, (2) supply quantity,
(3) demand timing, and (4) demand quantity. The
events can cause one or more planned jobs to be
unattainable. If a vender informs that the supply for
a purchase order will be delayed or insufficient in
quantity, then supply uncertainty happens and some
procurement jobs could be affected by the uncertainty.
If a customer desires to have an earlier delivery than
the promised due date or wants an extra quantity, then

137

demand uncertainty occurs and the job of finished

product becomes unattainable.
APPCS responses to the events by executing planning and scheduling again. The demand whose jobs
become infeasible or unattainable will be added to the
rerun list. Except for the in-processing and released
jobs, the previously planned jobs belong to the rerun
demands will be abandoned. The reserved capacity of
the resources by those jobs is freed, and the assigned
quantity is cancelled. The processing and scheduling
run again for the demands according to priority based
on the in-processing jobs, inventory, and released
purchased orders.
Fig. 4 depicts how state (Sn, n 0; 1; . . .) of a
demand is changed by the coming unpredicted events
(En, n 1; 2; . . .) during processing the demand.
Execution of planning and scheduling PS( ) at notification time tn remedies the change. In the figure, a
dotted line with its start point in the time axis and end
arrow pointing to a job shows an event, and a bold line
with an arrow indicates a state change. In each state, a
square shows a job, a filled square a released job, a
square of dotted line a finished job.

3. Formulation of the APPCS by UML

3.1. Class diagram
Class diagram shows static structure of a model, in
particular, the things that exist (such as classes and
types), their internal structure, and their relationships
to other things. The class diagram of the APPCS

Fig. 4. State changes of a demand by events.

138

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

Fig. 5. Class diagram of APPCS.

model is shown in Fig. 5. In the figure, a rectangle

indicates a class, a solid line among classes shows an
association, and a dashed line between an association
and a class suggests that the class is an association
class. Within the rectangle, name, attributes and methods of the class are listed.
The Part class is abstracted from finished products,
assemblies, and raw materials. The value of the attribute procureLeadTime is the time for procuring or
outsourcing a part. A set of operations is specified for a
finished product and an assembly. The Operation class
is modeled from the operations and there is a composition association from the Part class to the Operation

class. The association is also represented by a reference shown in the attribute area of the Part class. The
reference begins with a / to distinguish it from the
other attributes.
Attributes of the Operation class including setupTime, and processTime are used in calculating the total
processing time. A BOM of a part can be regarded as a
set of links that connect the part to its input parts, and
in each link a unit quantity is specified. An association
with its both ends attaching to the Part class is
abstracted from the links, and an association class
Bom is necessary for the association to contain the
attribute unitQty. There are constraints on preventing

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

the product structure from an endless loop of BOM

explosion. For a part, its input links and output links
are abstracted to be inBom and outBom references,
respectively.
The WorkCenter class is an abstraction of work
centers, and the Resource class is an abstraction of
resources. There is a many-to-many association
between the two classes because a work center can
enroll more than one resource, and a resource is
possible to work for more than one work center. An
association from the Operation class to the WorkCenter class suggests that each operation is assigned
a work center for manufacturing. A set of workable
intervals is specified for a resource. The Shift class
with attributes of startEpk and finishEpk is abstracted
from the intervals, and there is a composition association from the Resource class to the Shift class.
A job is defined as a net requirement of part that is
manufactured or procured during a period of time. A
job is generated as a result of planning process, and its
start epoch and finish epoch are known after scheduling is completed. A job will be released to the shop
floor when it is time to start the job, and it can be
offered or assigned to other jobs after the job is
finished. The inventory on hand can be viewed as a
finished job of manufacturing or procurement. The
WIP can be viewed as an in-processing job. By treating them as a job, the assignment from them to a job
and inventory processing can be omitted from the
abstraction work. Fig. 6 shows an abstracted version
of Fig. 3a.
The Job class is an abstraction of the jobs. Its
attributes are part for keeping the request part, netReq

139

for net requirement, startEpk for job starting epoch,

and finishEpk for job finishing epoch. The Link association class with an attribute linkQty is to describe the
request-offer links between two jobs. The attribute
keeps the value of the dependent requirement. For a
job, the links connect to its input jobs are abstracted as
inLink reference, and the links connect to its output
jobs as outLink reference.
The Assign association class is abstracted from the
assignments from a released job r to a planning job s.
The job s is an output assignment job of the job r;
while the job r is an input assignment job of the job s.
The only attribute assignQty of the class holds value of
the assigned quantity. For a job, the assignments
connect to its input assignment jobs are abstracted
as inAssign reference, and the assignments connect to
its output assignment jobs as outAssign reference.
As shown in Fig. 6, the link is shown as a solid line
between two jobs, and the assignments of quantity 10,
5, and 5 from jobs u; v; and w to job i are illustrated by
arrow lines. The job i has two input links, one output
link, three input assignments, and no output assignment.
The independent requirement of a job is from the
request quantity of a demand. The demanded part
(normally finished product), request quantity, and
due date are specified for each demand. The Demand
class with attributes of part, demandQty and dueEpk is
abstracted from the demands. A demand is transformed
to a set of jobs by planning and scheduling. The
request-offer relationship between the planned jobs
forms a tree of jobs. We can traverse all the planned
jobs of a demand if the demand has a connection with

Fig. 6. Instances of Job, Link, and Assign.

140

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

the root job. Conversely, the root job and its input
assignment jobs can pass the finished product to the
demand through the same connection. Hence, a bidirectional association is specified between the
Demand class and the Job class. In Fig. 6, a dotted
line between the demand d and the job i represents
such connection.
Net requirement of a manufacturing job is transformed to a set of schedules by scheduling process.
The Schedule class is abstracted from the schedules.
For a valid schedule, the processing operation and a
workable interval within a shift of a resource must be
specified. The operation is abstracted as operation
reference to the Operation class. The workable interval of a resource is modeled as attributes startEpk and
finishEpk, and a shift reference to the Shift class.
To prevent a resource from assigning a reserved
area of its shifts to the other jobs, the reserved areas
within a shift should be managed. A schedule reference of the Shift class to the Schedule class is established for this purpose. It is necessary for a
manufacturing job to access its schedules. Hence, a
composition association from the Job class to the
Schedule class is designed. A schedule reference
specified in the Job class plays a role in distinguishing
a manufacturing job with a procurement job.
The net requirements of procurement jobs are supplied by releasing purchase orders. The Supply class is
an abstraction of the purchase orders. For a purchase
order, request part (normally raw material), promised
delivery epoch, supply quantity are specified. These
values are kept in part, promiseEpk, supplyQty, the
reference or attributes of the Supply class. A purchase
order can supply one or more than one procurement
job. Since there is no need to divide the net requirement into more than two purchase orders, a job can
only be supplied by a purchase order. An association
between the Supply class and the Job class abstracts
such supplement links.
3.2. Constraints
The UML model of APPCS should satisfy certain
conditions. The conditions are specified to restrict
some actions of the model elements. A constraint is
a semantic relationship that must be maintained;
otherwise, the system described by the model is
invalid [8]. The semantics is described in terms of

the set theory. Regarding Part, WorkCenter, Resource,

Shift, Demand, Job, and Shift as tables, i 2 A means
i is an element of a table A, and a b implies a and
b are the same elements.
3.2.1. Planning
(1) (8d 2 Demand)(d:part d:offerJob:part)
(2) (8i 2 Job)((8j 2 i:outAssign)(i:part j:requestJob:part) and (8j 2 i:inAssign)(i:part j:offerJob:part))
(3) (8i 2 Job)(8j 2 i:outLink)(9k 2 Bom)(k:parentPart j:requestJob:partandk:childPart i:part)
Constraint (1) requires that for a demand, the part of
the offering job must be the same with the part of the
demand. Constraint (2) stipulates that for a job, its input
assignment jobs and output assignment jobs must produce or procure the same part with the job. Constraint (3)
gives that for a job a, for any its request job b, the pairs
(b.part, a.part) must be defined in the bill of materials.
( 4 ) ( 8i 2 Job) ( 8j 2 i:outAssign) ( 8k 2 i:outLink) (j:offerJob:finishEpk k:requestJob:startEpk)
(5) (8i 2 Job)(8j 2 i:outLink)(i:finishEpk
j:requestJob:startEpk) P
( 6 ) ( 8i 2 P
Job) ( i:netReq  d2i:outDemand
d:demandP
Qty j2i:outLink j:linkQty k2i:inAssign k:assignP
Qty m2i:outAssign m:assignQty)
Constraint (4) gives that to assign a job i to a job j,
the job i must be delivered in time to support all
request jobs of job j. As shown in Fig. 6, the finish
epochs of jobs u and w are earlier than start epoch of
job r. Constraint (5) provides that for a job must be
finished before all of its request jobs start. Constraint
(6) gives a minimum level of the net requirement. The
surplus of net requirement might be reserved for the
sake of safety stock.
3.2.2. Scheduling
(7) (8i 2 Resource)(8j; k 2 i:shift)(k:startEpk;
k:finishEpk \ j:startEpk; j:finishEpk )
(8) (8i 2 Job)(8j 2 i:schedule)(j:shift:resource
2 j:operation:processWkCtr:enrollResource)
( 9 ) ( 8i 2 Job) ( 8j 2 i:schedule) ( j:startEpk; j:finishEpk  j:shift:startEpk; j:shift:finishEpk )
(10) (8i 2 Shift)(8j; k 2 i:schedule)(k:startEpk;
k:finishEpk \ j:startEpk; j:finishEpk )

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

Constraint (7) restricts a resource to join at most one

shift simultaneously. When choosing a resource for an
operation, the resource must be one of the resources
enrolled in the assigned work center of the operation
by following constraint [8]. Constraint (9) shows that
the interval of any schedule must be a subset of the
specified shift from, and (10) prevents the reserved
shift being used by other schedules.
3.2.3. Procurement
(11) (8i 2 Supply)(8j 2 i:requestJob)(i:part
j:part)
P
(12) (8i 2 Supply)(i:netReq  k2i:requestJob k:netReq
and i:promiseEpk  Minm2i:requestJob m:finishtEpk)
Constraint (11) requires that the purchasing part
should be the same with the part of the request jobs.
Constraint (12) gives that quantity of a supply must not
be less than the sum of net requirements of all its
request jobs, and the promise (delivery) epoch of a
supply must be earlier than the earliest finish epoch
among the request jobs. The surplus might be reserved
for the sake of safety stock, and the earlier delivery
than required could be for the reason of safety lead
time.
3.3. Behavioral model
3.3.1. State transition of a job
A job has five states in its life cycle as shown in
Fig. 7. They are created, planned, scheduled,
released, and finished. In the figure, the ellipse
shows a state, a solid cycle an initial state, a solid cycle
with double lines a final state, and the arrow line

141

connecting two states an event. Two types of event are

used in the state chart. A change event occurs when an
expression becomes true as a result of a change in
value of one or more attributes or associations. A call
event represents the reception of a request to synchronously invoke a specific operation. A state is driven by
an event to jump to another state.
A job is generated to represent a net requirement.
Value of the attribute netReq is known after the job
runs planning( ). It is shown by a sequence diagram in
Fig. 8a, and the methods used in this section are listed
in Appendices A.1A.3. A sequence diagram presents
an interaction between instances. In a sequence diagram, the vertical dimension represents time and the
horizontal dimension represents different instance. In
Fig. 8a, the method getDueFinishEpk( ) gets the minimum request epochs among the requirements as the
due finish epoch, and getRequestQty( ) gets the total
gross requirements. Then the procedure enters a loop
to assign unused quantity of other jobs, including
inventory on hand (finished job), released purchase
order (procurement job), and WIP (in-processing job),
to the planning job. The method getDisposableQty( )
returns disposable quantity of a job. Finally, the
unassigned part of gross requirement becomes net
requirement of the job.
A planned job can go to the scheduled state by
scheduling. The scheduling process reserves capacity
of resources for all the operations of a job. The process
is bi-directional. Backward scheduling starts to reserve
capacity for the last operation from a due finish epoch
and ends by the first operation. The due finish epoch is
the earliest start epoch among the request jobs. Conversely, forward scheduling begins with the first operation by starting from a due start epoch, i.e. the latest

Fig. 7. Sate chart diagram of a job.

142

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

Fig. 8. Sequence diagrams of planning( ) and scheduling( ) of the job.

finish epoch among the offer jobs. Fig. 8b shows a

sequence diagram of backwardScheduling( ), and the
methods in the diagram are listed in Appendices A.1
A.3.
The figure shows that backward scheduling of a job
begins with a loop starting from the last operation to
the first one. At the beginning of the loop, the method
chooseResource( ) of the WorkCenter class picks a
resource from the work center to be responsible for
an operation. There are some criterions for choosing
the resource. In case of backward scheduling, for
example, the resource that starts the operation the
latest or has the lowest capacity rate during a period
of time is chosen. In case of forward scheduling, the
resource that finishes the operation the earliest can be
selected.
After determining a resource for an operation, the
available shift of the resource is reserved by the
necessary processing time of the operation The time
is estimated by a summation of setup time and processing time. The processing time is a multiplication of
net requirement and unit processing time. The processing time is provided by the resource in the form of
segmented intervals or a continuous one. The procedure enters another loop to search available intervals

and generate schedules for the processing time of an

operation. The method getPrevFreeInterval( ) of the
Resource class returns a specified length of free interval within a shift before a specified epoch. A schedule
will be generated for a returned interval. Finally, a set
of schedules is obtained from scheduling all operations of a job, and the schedules give the planned start
epoch startEpk and the planned finish epoch finishEpk
of the job.
There is no operation for a procurement job; hence
it is scheduled by considering its procurement lead
time only. If a finish due epoch is specified for a job,
then the backward scheduling treats the due epoch as
the finish epoch and obtains the start epoch by subtracting the lead time from the finish epoch. If the
result of backward scheduling is infeasible, then the
schedules are cancelled by method cancelScheduling( ) and another set of schedules are generated by
forward scheduling. The method forwardScheduling( ) uses the same logic with the backward scheduling. Sometimes, the planning result of a job affected
by uncertainty will be cancelled by the method cancelPlanning( ).
A job enters the released state after the present
time goes to startEpk. A manufacturing job is released

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

to the workshop for production. A procurement job is

transformed to a purchase order, and released the order
to a vender. We assume that a released job cannot be
canceled, i.e. it is unable to go back to the previous
states. After a job is released, it can assign its disposable quantity to other jobs. A released manufacturing job is possibly delayed by an unpredictable
resource breakdown, and the vender can delay a
released procurement job. In such cases, forwardScheduling( ) is executed to remedy the change.
If a job is finished in an epoch, then it is reported by
triggering the method reportFinish( ), and the job goes
to the finished state. The epoch must be before the
planned finish epoch. A finished job is allowable to be
input to its request jobs, or to be the inventory on hand.
Finally, a finished job enters the final state when all the
disposable quantity is used up. The getDisposableQty( ) method is called to get the unreserved quantity of a job.
3.3.2. Sequential flow of a demand
A demand is a basic unit of planning and scheduling.
The planning and scheduling of a demand is executed
by the method planningScheduling( ), and it will output
a set of jobs and a set of schedules for each of the job.
Fig. 9 shows a sequence diagram of the method, and the
detailed programs of the methods inside are given in
Appendix A.3. In the figure, PSet, and BSet are sets of
jobs waiting for running planning, and backward scheduling severally. The add(i) method of the set adds a
job i to the set, and the get( ) method gets the next job
and remove the job from the set.
If it is the first time to execute planning and
scheduling of a demand, then the method will generate
jobs according to BOM and build request-offer links
between them by the buildLinks( ) method. To make a
finished product, some parts, such as screws, are
possibly used in different assemblies. This method
acts as a preparatory work of accumulating all the
requirements of such part in a job. Otherwise, calling
the cancelPlanningScheduling( ) method to cancel the
unreleased jobs and their schedules.
Then two synchronized sub-processes, the planning
process and scheduling process, will be triggered if
there is any job in the PSet and BSet, respectively. The
method planning( ) will be triggered if there is any job
waiting in the PSet. After job planning, if net requirement of a job is greater than 0, then the job is added to

143

the BSet. The backwardScheduling( ) is called by the

job waiting in the BSet. After job scheduling, its offer
jobs that are capable of planning will be added to the
PSet. A job is capable of planning, if it has no request
job or all of its request jobs are scheduled. The
condition is verified by the method allOutJobScheduled( ) of the Job class. The planning and scheduling
of a demand first performs in a top-down direction
from the finished product level to the raw material
level by a combination of job planning processes and
job backward scheduling processes until the PSet and
the BSet are empty.
The job with the highest priority can first reserve the
free quantity of the released jobs. The job with the first
priority of executing scheduling can reserve the free
capacity of the resource. The sequence of jobs executing planning and scheduling can uniquely determine a
set of jobs and their schedules. The sequence can be
determined by choosing: (1) either planning process or
scheduling process, and (2) the next job from the PSet
and the BSet. Some rules help determining (1). For
example, a breadth-first rule assumes that planning is
triggered when there is no job in BSet, and scheduling
is triggered when there is no job in PSet. A depth-first
rule assumes that PSet is a first-in-last-out (FILO)
stock, and a job runs the scheduling as soon as it enters
BSet. To determine (2), selecting the job that has the
earliest finish epoch within PSet or BSet is the rule that
usually used. Fig. 10 shows sequences of planning and
scheduling of a demand m by assuming depth-first
rule, breadth-first rule, and no rule. In the figure, B
indicates the BSet, P the PSet, plan(y) planning job y,
sche(x) scheduling job x, and element a within the sets
means the job of a part a.
The planning and backward scheduling generates a
set of jobs and each job possesses a set of schedules.
The jobs together with the request-offer relationships
form a tree. The root node of the tree is the job of
finished product. If the result shows that the start
epoch of any job locates in the past, then the result
is infeasible and should be abandoned. Instead, the
bottom-up approach that performs forward scheduling
from the leaf jobs to the root job is adopted. In Fig. 9,
FSet is a set of jobs waiting for forward scheduling.
The schedules of all the jobs in the tree are canceled by
executing cancelScheduling( ). The job capable of
forward scheduling is the job with no input job or
all of its input jobs are scheduled. The condition is

144

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

Fig. 9. Sequence diagram of planningScheduling( ) of the demand.

Fig. 10. Sequences of planning and backward scheduling.

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

verified by the method allInJobScheduled( ) of the Job

class.
The jobs capable of forward scheduling in the tree
are the initial jobs of FSet. The method forwardScheduling( ) is called by the job waiting in FSet, and its
request jobs that are capable of forward scheduling
will be added to the FSet again. The sequence of
forward scheduling is determined by choosing the next
job in FSet. The priority rule, for instance, can be the
shortest processing time, earliest due epoch, and
smallest net requirement, etc.
A demand begins to production when any of its jobs
is released. During production, if any uncertainty
occurs to a demand, then the demand must run planningScheduling( ) again to remedy the change. After
the root job of a demand finishes manufacturing, the
demand is finished and the finished product will be
shipped to the customer.
3.3.3. State transition of procurement job
After all the demands finish planning and scheduling, purchase orders are generated to meet the net
requirements of the procurement jobs. The procurement jobs that request the same part (usually raw
material) and whose start epochs are within a period
of time are usually integrated as a purchase order.
As soon as a purchase order is created, it is released
to a vender, and all the request procurement jobs in
requestJob are marked with released automatically,
and they will go to the finished state after the supply
is delivered. If supply uncertainty occurs to a purchase
order, then the demands that directly or indirectly
request part from the purchase order must execute
planningScheduling( ) again to remedy the change.

4. Testifying APPCS model

In order to testify the proposed UML model of
APPCS, we discuss two issues: a simulator and an
instance.
4.1. Simulator
We implemented it as part of a simulator [9].
The simulator is used in investigating the setting of
safety stock or safety lead time to protect against
unexpected events by agile rescheduling. The simu-

145

lator is implemented by integrating VCTM and

MSSQLTM database.
4.2. Instance of APPCS
To give a whole image of the APPCS and to testify
the model, we show an instance of the model in this
section. Fig. 11a shows the instances of production
data and initial data for the example. The instances are
contained in tables: Part, Operation, Bom, WorkCenter, Resource, Shift, Schedule, and Demand. Elements
of the tables follow the definition of class diagram in
Fig. 5 and the constraints in Section 3.2. Initially, a
schedule from epoch 100200 of resource y is specified for maintenance.
Two instances in the Demand table run planningScheduling( ) in epoch 0 by following the EDD
rule. In case of backward scheduling of a job, the
chooseResource( ) obeys the latest start epoch rule,
and in case of forward scheduling, the earliest finish
epoch rule is adopted. A result of planning and backward scheduling of demand d1 is shown in Fig. 11b by
tables of Job, Schedule, and Shift. The job sequence of
planning and scheduling is 14.
Since the results show that job 3 and job 4 start from
the past, hence they are abandoned. Forward scheduling is used alternatively for demand d1 by the job
sequence 3, 4, 2, and 1. The result of planning,
scheduling, and procuring of demand d1 and d2 is
shown in Fig. 11c by tables of Demand, Job, Link,
Assign, Schedule, and Supply. The procurement jobs 4
and 6 are integrated to form a purchase order s2. Then
the production activity begins according to jobs and
supplies in Fig. 11c.
1. Epoch 0: Purchase orders s1 and s2 are released to
suppliers, and the corresponding procurement jobs
3, 4, 6 enter the released state.
2. Epoch 10: Purchase order s3 is released, and job 7
becomes released.
3. Epoch 40: Supply s2 arrives, and jobs 4 and 6 enter
the finished state.
4. Epoch 50: Supply s1 arrives, and job 3 enters the
finished state. Operation c10 of job 2 begins
with consuming 20 units of part d from job 3 and
40 units of part e from job 4. Disposable quantity
of job 3 becomes 20, and job 4 is used up and
destroyed.

146

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

Fig. 11. An example of the APPCS model.

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

5. Epoch 60: The supplier informs that the arrival of

supply s3 will be delayed for 20 time units, i.e.
becomes epoch 110. Since demand d2 is affected
by the change, so the not started job (job 5) of the
demand and its schedules are cancelled. Demand 2
runs planningScheduling( ) again to remedy the
change based on jobs 6 and 7. In Fig. 11d, the
result shows that the supply change delays
demand d2 for 20 time units.
6. Epoch 110: The arrival of the delayed supply s3
makes job 7 enter finished state. Job 8 starts and
consumes jobs 9 and 10. Job 6, 7, 9, and 10 are
used up and thus destroyed.
7. Epoch 140: Job 2 is finished. Operation a10 of job
1 starts with consuming 10 of part c from job 2
and 20 of part d from job 3. Jobs 2 and 3 are used
up and thus destroyed.
8. Epoch 200: The customer requests two more units
of demand 1 and desires to know the earliest
possible delivery date. Since the only job that
belongs to demand 1 is ongoing, it cannot be
cancelled. Demand 1 runs planningScheduling( )
again based on job 1. Fig. 11e shows that the
additional demand can be offered at epoch 324
if purchase orders s4 and s5 can be released
immediately.
9. After epoch 220: Job 1 finished at epoch 220.
Supply s5 arrives at epoch 240, and s4 at 250. Jobs
13 and 14 enter finished state and provide the
necessary materials for job 12, which starts at
epoch 250. At epoch 270, job 8 is finished and
offered to demand d2. At last, job 11 is finished
and offers to demand d1 at epoch 324.

147

If a priority rule and the corresponding parameters,

such as lot size, lead time, or safety stock is specified,
then a feasible production plan can be generated and
regenerated against uncertainties by first backward
scheduling and then forward scheduling. The APPCS
model has been applied to an implementation of a
simulator successfully. Furthermore, the APPCS
model is demonstrated and testified by an example,
which shows how a demand runs planning and scheduling, and how the demand reacts to the supply and
demand change during production control.
Hatchuel et al. [1] pointed out that during the last
four decades, continuing development of industrial
technology has generated a new make-to-order industrial type. Under such a competitive environment in
the industries, customers are usually allowed to
change not only the quantity, but also the specification
or the style of the product after they made an order.
The immediate planning and scheduling can respond
to the change with higher service level, better resource
utilization, and less material loss. The proposed
APPCS model makes the immediate planning and
scheduling possible.
In order to control a business process with high
quality of performance, qualitative analysis of dynamic
property such as [10,11] is not sufficient. The design of
dynamics of a business process is necessary. If we
could bring planning components into the design of
business processes, then the whole control mechanism
can be explicitly managed. The result of this paper also
plays a basic role for that purpose.

Acknowledgements
5. Conclusion
We have proposed a UML model of APPCS. In the
model, Part, Bom, Operation, WorkCenter, Resource,
Shift, Demand, and Supply classes and their associations are defined. Job and Link classes and their
associations abstract the hierarchy structure of jobs.
The Schedule class is an abstraction of the feasible
schedules, each of which describes who, where, when,
and how long of an operation. The Assign class
abstracts the assignments from in-processing jobs to
the planning jobs when planning and scheduling is
executed again because of uncertainties.

This research was partially supported by the Ministry of Education, Science, Sports and Culture of
Japan, Grant-in-Aid for Scientific Research (C)
13630132, and by the University of Tsukuba, Special
Research Grant (S). The authors are grateful to SAP
JapanTM and FrontStep JapanTM (formerly, SIMIX
Japan) for their support and help.

Appendix A.
A method of the operation in Fig. 5 is listed in the
appendices for reference. The procedure of the method

148

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

here is described in terms of programming logic and set

theory by assuming Part, WorkCenter, Resource, Shift,
Demand, Job, and Shift as existing tables. In some of the
procedures, suppose S is a set of elements, S.add(i)

method adds a job i to the set, S.delete(i) removes a

job i from the set, S.get( ) gets the next element and
remove it from the set, and S.search(c1, c2, . . .) searches
the set for an element with conditions c1, c2, . . ..

A.1. Methods of Resource class

Interval Resource.getPrevFreeInterval (dueEnd: Epoch, length Time)
//Returns a resources free interval that is located before an epoch and of a specified length
Interval i : (Null, Null, Null)
FOR ALL f 2 {s | s 2 this.shift (s.startEpk < dueEnd} DESCENDING BY f.startEpk
IF f.finishEpoch < dueEnd THEN dueEnd : f.finishEpoch;
Schedule H : {h | h 2 f.schedule (h.startEpk < dueEnd};
i.finishEpk : Max {t | t 2 [ f.startEpk, dueEnd ] & (8h 2 H) t 2
= [ h.startEpk, h.finishEpk ]};
IF i.finishEpk 6 Null
i.startEpk : Max {h.finishEpk | h 2 H (h.finishEpk < i.finishEpk};
IF i.startEpk Null THEN i.startEpk : f.startEpk;
IF length < (i.finishEpk  i.startEpk)
i.shift : f;
RETURN i;
ENDIF
ENDIF
ENDFOR
RETURN (Null, Null, Null);
Interval Resource.getNextFreeInterval (dueStart: Epoch, length Time)
//Returns a resources free interval that is located after an epoch and of a specified length
Interval i : (Null, Null, Null)
FOR ALL f 2 {f | f 2 this.shift (f.finishEpk > dueStart} ASCENDING BY f.finishEpk
IF f.startEpoch > dueStart THEN dueStart : f.startEpoch;
Schedule H : {h | h 2 f.schedule & h.finishEpk > dueStart};
i.startEpk : Min {t | t 2 [ dueStart, f.finishEpk ] & (8h 2 H) t 2
= [ h.startEpk, h.finishEpk ]};
IF i.startEpk 6 Null
i.finishEpk : Min {h.startEpk | h 2 H & h.startEpk > i.startEpk};
IF i.finishEpk Null THEN i.finishEpk : f.finishEpk;
IF length < (i.finishEpk  i.startEpk)
i.shift : f;
RETURN i;
ENDIF
ENDFOR
RETURN (Null, Null, Null);

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

A.2. Methods of Job class

Epoch Job.getDueFinishEpk( )
//Returns the due finish epoch of a job, the epoch is the earliest one among its request jobs.
Epoch dueEpkForRequestJob : Min{l.requestJob.startEpk | l 2 this.outLink};
Epoch dueEpkForDemand : Min{d.dueEpk | d 2 this.outDemand};
RETURN Min(dueEpkForRequestJob, dueEpkForDemand);
Epoch Job.getDueStartEpk( )
//Returns the due start epoch of a job, the epoch is the latest on among its offer jobs.
RETURN Max{l.offerJob.finishEpk | l 2 this.inLink};
Qty Job.getRequestQty( )
//Returns the
Ptotal independent requirements and
P dependent requirements of a job
RETURN ( {l.linkQty | l 2 this.outLink} {d.demandQty | d 2 this.outDemand});
Qty Job.getDisposableQty( )
//Returns the disposable (assignable)
P quantity of a job
Qty safetyStock : this.netReq

{i.assignQty | i 2 this.inAssign}  this.getRequestQty( );

P
RETURN (safetyStock  {o.assignQty | o 2 this.outAssign});
Boolean Job.allInJobScheduled( )
//Returns true if all the offer jobs of a job is in the scheduled state
FOR ALL l 2 this.inLink
IF l.offerJob.netReq 6 0 AND l.offerJob.finishEpk Null THEN RETURN(False);
ENDFOR
RETURN(True);
Boolean Job.allOutJobScheduled( )
//Returns true if all the request jobs of a job is in the scheduled state
FOR ALL l 2 this.outLink
IF l.requestJob.netReq 6 0 AND i.requestJob.startEpk Null THEN RETURN(False);
ENDFOR
RETURN (True);
void Job.planning( )
//Planning a job
Epoch dueEpk : this.getDueFinishEpk( );
Qty reqQty : this.getRequestQty( );
Job AJ : {j | j 2 Job & j.part this.part & j.finishEpk dueEpk & j.getDisposableQty( ) > 0};
FOR ALL i 2 AJ DESCENDING BY i.finishEpk
Qty assignQty : i.getDisposableQty( );
Assign g : NEW Assign (requestJob this, offerJob i, assignQty assignQty);
this.inAssign.add(g);
i.outAssign.add(g);
IF reqQty > assignQty
g.assignQty : assignQty;
reqQty : reqQty  assignQty;
ELSE
g.assignQty : reqQty;
reqQty : 0;

149

150

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

BREAK;
ENDIF
ENDFOR
this.netReq : reqQty;
RETURN
void Job.backwardScheduling( )
//Scheduling a job backwardly from the due finish epoch of the job
Epoch dueFinishEpk : this.getDueFinishEpk( );
IF this.part.operation
this.finishEpk : dueFinishEpk;
this.startEpk : dueFinishEpk  this.part.procureLeadTime;
ELSE
FOR ALL o 2 this.part.operation DESCENDING BY o.no
Time reqTime : o.setupTime o.processTime  this.netReq;
Resource r : o.processWkCtr.chooseResource (dueFinishEpk, reqTime);
WHILE reqTime > 0
Interval i : r.getPrevFreeInterval(dueFinishEpk);
reqTime : reqTime  (i.finishEpk  i.startEpk);
IF reqTime < 0 THEN i.startEpk : i.startEpk  reqTime;
Schedule s : NEW Schedule (job this, operation o, shift i.shift,
startEpk i.startEpk, finishEpk i.finishEpk);
this.schedule.add(s);
i.schedule.add(s);
dueFinishEpk : i.startEpk;
ENDWHILE
ENDFOR
this.startEpk : dueFinishEpk;
this.finishEpk : Max{s.finishEpk | s 2 this.schedule};
ENDIF
RETURN
void Job.forwardScheduling(now Epoch)
//Scheduling a job forwardly from the present time or from the due start epoch of the job.
IF this.part.operation
this.startEpk : now;
this.finishEpk : this.startEpk this.part.procureLeadTime
ELSE
Epoch dueStartEpk : this.getDueStartEpk( );
FOR ALL o 2 this.part.operation ASCENDING BY o.no
Time reqTime : o.setupTime o.processTime  this.netReq;
Resource r : o.processWkCtr.chooseResource (dueStartEpk, reqTime);
WHILE reqTime > 0
Interval i : r.getNextFreeInterval(dueStartEpk);
reqTime : reqTime  (i.finishEpk  i.startEpk);
IF reqTime < 0 THEN i.finishEpk : i.finishEpk reqTime;
Schedule s : NEW Schedule (job this, operation o, shift i.shift,
startEpk i.startEpk, finishEpk i.finishEpk);
this.schedule.add(s);

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

i.schedule.add(s);
dueStartEpk : i.finishEpk;
ENDWHILE
ENDFOR
this.finishEpk : dueStartEpk;
this.startEpk : Min{s.startEpk | s 2
this.schedule};
ENDIF
RETURN
void Job.cancelPlanning( )
//Canceling the result of job planning
this.netReq : 0;
DESTROY ALL this.inAssign;
FOR ALL il 2 this.inLink DO il.linkQty : 0;
RETURN
void Job.cancelScheduling( )
//Canceling the result of job scheduling, either
backward scheduling or forward scheduling
this.startEpk : Null;
this.finishEpk : Null;
this.supply: Null;
DESTROY ALL this.schedule;
RETURN

A.3. Methods of Demand class

void Demand.buildLinks( ):
//This method constructs a request-offer relationship
between jobs of a demand.
Job i : NEW Job (part this.part);
i.outDemand.add(this); this.offerJob : i;
Job Lset :{i}, TSet : ;
WHILE LSet 6
Job j : LSet.get( );
Job k : TSet.search(part j.part);
IF k Null
TSet.add(j);
FOR ALL ib 2 j.part.inBom
Job oj : NEW Job (part ib.childPart);
LSet.add(oj);
Link l : NEW Link (requestJob j,
offerJob oj);
j.inLink.add(l); oj.outLink.add(l);
ENDFOR
ELSE

151

FOR ALL ol 2 j.outLink DO ol.offerJob : k;

DESTROY j;
ENDIF
ENDWHILE
RETURN;
void Demand.planningScheduling(now: Epoch)
//Planning and scheduling of a demand to generate a
feasible plan for the demand
IF this.offerJob 6 Null THEN this.cancelPlanningScheduling(now) ELSE this.buildLinks( );
Job Pset :{this.offerJob}, BSet : ;
Boolean ret : True;
WHILE PSet 6 OR BSet 6
THREAD
Job pj : Pset.get( );
pj.planning( );
IF pj.netReq > 0
BSet.add(pj);
FOR ALL il 2 pj.inLink
Bom b : Bom.search(parentPart pj.part,
childPart il.offerJob.part);
il.linkQty : b.unitQty  pj.netReq;
ENDFOR
ENDIF
ENDTHREAD
THREAD
Job bj : BSet.get( );
bj.backwardScheduling( );
IF bj.startEpk < now THEN ret : False;
FOR ALL il 2 bj.inLink
IF il.offerJob.allOutJobScheduled( ) True
THEN PSet.add(il.offerJob);
ENDFOR
ENDTHREAD
ENDWHILE
IF ret False
Job CSet :{this.offerJob}, FSet : ;
WHILE CSet 6
Job cj : CSet.get( ); cj.cancelScheduling( );
IF cj.inLink THEN Fset.add(cj);
ELSE FOR ALL il 2 cj.inLink DO
CSet.add(il.offerJob);
ENDIF
ENDWHILE
WHILE FSet 6
Job fj : FSet.get( ); fj.forwardScheduling(now);
FOR ALL ol 2 fj.outLink

152

T. Tsai, R. Sato / Computers in Industry 53 (2004) 133152

IF ol.requestJob.allInJobScheduled( ) True
THEN FSet.add(ol.requestJob);
ENDFOR
ENDWHILE
ENDIF
RETURN
void Demand.cancelPlanningScheduling
(now: Epoch)
//Canceling the result of planning and scheduling
of a demand
Job Cset :{this.offerJob};
WHILE CSet 6
Job cj : CSet.get( );
IF cj.startEpk > now THEN
cj.cancelScheduling( ); cj.cancelPlanning( );
FOR ALL il 2 cj.inLink
il.linkQty : 0;
IF il.offerJob.startEpk 6 Null THEN
CSet.add(il.offerJob);
ENDFOR
ENDWHILE
RETURN
References
[1] A. Hatchuel, D. Saidi-Kabeche, J.C. Sardas, Toward a new
planning and scheduling approach for multistage production
system, International Journal of Production Research 35 (3)
(1997) 867886.
[2] A.W. Scheer, Business Process Engineering, 2nd ed., Springer, Berlin, 1994.
[3] D.C. Whybark, J.G. Williams, Material requirements planning under uncertainty, Decision Sciences 7 (1976) 595
606.
[4] D.E. Shobrys, D.C. White, Planning, scheduling and control
system: why cannot they work together, Computers and
Chemical Engineering 26 (2002) 149160.
[5] E.A. Silver, D.F. Pyke, R. Peterson, Inventory Management
and Production Planning and Scheduling, 3rd ed., Wiley, New
York, 1998.

[6] L.M. Sanchez, R. Nagi, A review of agile manufacturing

system, International Journal of Production Research 39 (16)
(2001) 35613600.
[7] N.A.J. Hastings, C.H. Yeh, Job oriented production scheduling,
European Journal of Operational Research 47 (1990) 3548.
[8] OMG Unified Modeling Language Specification (Action
Semantics), Version 1.4, OMG, 2002.
[9] R. Sato, T.L. Tsai, An agile production planning and control
with advance notification to change schedule, International
Journal of Production Research, in press.
[10] R. Sato, H. Praehofer, A discrete event model of business
systema systems theoretic foundation for information
systems analysis, Part 1, IEEE Transactions on Systems,
Man, and Cybernetics 27 (1997) 110.
[11] R. Sato, Meaning of dataflow diagram and entity life
historya systems theoretic foundation for information
systems analysis, Part 2, IEEE Transactions on Systems,
Man, and Cybernetics 27 (1997) 1122.
[12] T.E. Vollman, W.L. Berry, D.C. Whybark, Manufacturing
Planning and Control Systems, McGraw-Hill, New York,
1997.
[13] Y. Tu, Production planning and control in a virtual one-of-akind production company, Computers in Industry 34 (1997)
271283.
Tunglun Tsai is a Ph.D. candidate in the
Doctoral Program in Policy and Planning
Sciences at the University of Tsukuba,
Japan. He received his B.S. and M.S.
degrees in business Administration from
National Central University, Taiwan, and
System and Applied Mathematics from
University of Tsukuba in 1991 and 2000,
respectively. He has a 3 years experience
as a system analyst and project manager
at a system integration company. His research interests include
production information system, business process management, and
production planning, scheduling and control.
Ryo Sato received his B.Eng., M.Eng., and Ph.D. degrees from Tokyo
Institute of Technology in 1980, 1982 and 1986, respectively. He is
currently Professor of Institute of Policy and Planning Sciences,
University of Tsukuba, Japan. From 1994 to 1995, he was a visiting
scholar, Johannes Kepler University, Linz, Aurrria. His research
activities focus on applied general systems theory, discrete event
models, business process engineering, and information systems.