A Shop Floor Controller Class for
Computer Integrated Manufacturing
JEFFREY S. SMITH1 and SANJAY B. JOSHI2
ABSTRACT
Computer integrated manufacturing (CIM) has not yet provided the expected benefits for
small to medium volume discrete parts manufacturing operations. Typically, these systems come
in over budget and yet do not provide the promised flexibility. This can be directly attributed to
the high cost of control software development for integrated systems. Reusable software has
been proposed as a solution to the high software development and maintenance costs. One
paradigm for reusable software, object oriented modeling and programming, has emerged as an
important method for specifying, creating, and reusing software modules. This paper describes
an object oriented approach to specifying and developing shop floor controllers for automated
manufacturing environments. Specifically, a shop floor controller class hierarchy has been
developed based on the behavior of specific shop floor equipment and is described in this paper.
User experience has shown that software development time can be significantly reduced through
the use of this controller class.
1 Industrial Engineering Department, Texas A&M Univeristy, College Station, TX.
2
Industrial and Management Systems Engineering Department, Pennsylvania State University,
University Park, PA.
533580448
March 8, 2016
-1-
1. INTRODUCTION
Approximately 50-75% of manufactured parts produced in the United States are produced in
small to medium size batches. The current trend is some industries is to increase this percentage
even more and to reduce the batch sizes to approach single part production. Computer integrated
manufacturing (CIM) has been looked upon as a facilitator of these trends. With the entire shop
interconnected through a computer system, status information will be continuously available and
on-line decision making and control will be possible. However, CIM has not yet provided the
expected benefits in these small to medium volume discrete parts manufacturing environments.
The integration aspect of CIM seems to be the bottleneck. Although the computer hardware,
software, and networking components necessary for CIM are readily available over the counter,
the software necessary to perform integrated control over the individual shop floor components
has not been developed and commercialized. As a result, companies wishing to create CIM
systems must create custom implementations for each manufacturing system. These custom
implementations require not only manufacturing and manufacturing systems experts, but also
computer programming and networking experts. Furthermore, system maintenance and future
modifications to existing systems also requires significant expertise. This makes these systems
virtually out of reach of most of the small companies that could most benefit from CIM.
One solution to these problems is to develop “shrink wrapped” shop floor control software
which can be configured to any specific manufacturing system. This would make CIM available
to virtually any organization much as AutoCAD™ and other commercial CAD packages have
made advanced CAD technology available to anybody. While numerous off-the-shelf CIM
packages have been advertised, many of these appear to be shop floor monitoring packages and
include only minor provisions for shop floor control. Naylor and Maletz (1986) have stated that
the goal of off-the-shelf control software is probably impossible to completely attain, yet
consider that the goal can serve as a focus to work toward. We have been working towards this
goal for several years. In a previous paper, we described this use of existing software as a single
type of software reuse which can be applied to the development of shop floor control systems
(Smith and Joshi, 1992). A more promising approach to this problem is the use of object
oriented development and programming. In this previous paper, the use of object oriented
programming, and, specifically, the development of a shop floor equipment class is also
described. This class simplifies the development of the interface between the physical device
533580448
March 8, 2016
-2-
and the shop floor control system by providing a vendor independent interface based on
equipment type.
This paper presents a new development based on the equipment class. This original class has
been embedded inside a larger shop floor controller class, which exploits the similarities of
controllers at all levels in the control system. Also, the equipment behavior has been explicitly
defined within each class and provisions are provided for extending this class for devices which
exhibit specific behaviors not included in the current implementation. The controller behaviors
are described using a formal model called a message-based part state graph. These desriptions
are implementation independent and provide the input for an automatic software generation tool
(Smith and Joshi, 1993). Control software based on this class has been successfully implemented
in two separate laboratories, and implementation experience has shown that the software
development requirements have been greatly reduced through the use of this class.
After a brief background on object-oriented applications in manufacturing control in Section
2, Section 3 describes the control architecture underlying this work. Section 4 describes the shop
floor controller class hierarchy. Section 5 describes our implementation experience, and Section
6 provides some concluding remarks.
2. BACKGROUND
The term “object-oriented” is used to describe a method of software design and development
in which the system is organized as a collection of discrete objects. The implementation of each
object contains both the data and the behavior (procedures) for that object. In other words, an
object knows what it is and how it is supposed to behave. This is in contrast to conventional
software design where the behavior (procedures) and the data structures exist as separate entities
and are only loosely connected. Under the object-oriented paradigm, the software objects more
closely correspond to the physical objects that they model. Booch (1991) defines object-oriented
programming as “a method of implementation in which programs are organized as cooperative
collections of objects, each of which represents an instance of some class, and whose classes are
all members of a hierarchy of classes united via inheritance relationships.” For a more detailed
description of object oriented programming and development, see Booch, 1986; Coad and
Yourdon, 1991; Meyer, 1988; and Rumbaugh et al., 1991.
533580448
March 8, 2016
-3-
Naylor and Volz (1987) introduce the software/hardware component as an integral part of a
formal model of manufacturing control. A software/hardware component is an encapsulation of
a physical device (e.g. a machine tool, robot, AGV, etc.) and the software necessary for low-level
control of that device. The software components have three basic characteristics [Naylor and
Volz, 1987]:
1. a well defined public interface;
2. an internal implementation that is inaccessible to the user; and
3. the visible part and the inaccessible implementation of software components should be
separately compilable from the components that use them.
The main rationale for these characteristics is so that “plug compatible” modules could be
developed offsite based on provided specifications. The equipment vendors would then provide
the compiled software to meet the specifications along with the physical device. Naylor and
Volz point out that these new components not only must react to calls, but also must be able to
originate an event when necessary. These are termed active components. For example, a
machine tool would need to generate an unsolicited signal to the controller if a tool breaks.
Chaar et al. extend the work of Naylor and Volz by allowing hierarchically constructed
assembled software/hardware components and present several implementations of
software/hardware components [Chaar, 1990 and Hadj-Alouane et al., 1990].
Maimon and Fisher (1988) present the development of an Object-Based Controller (OBC).
The OBC is a hierarchical control system constructed as a goal-driven object/knowledge-based
system with progressing levels of abstraction. A detailed example implementation for a robotic
printed circuit board (PCB) assembly cell is described. Basnet et al. (1990) describe an objectoriented modeling environment for manufacturing systems. This system was developed based on
the need for a separation between the physical components and the information components in a
system. This separation is important so that changes in one can be done independently of the
other.
O'Grady and Seshadri (1991) introduce an object-oriented cell control model called X-Cell.
X-Cell is implemented in Scheme, a dialect of Lisp, using the object-oriented programming
environment SCOOPS. X-Cell consists of three modules. The scheduler checks for resource
533580448
March 8, 2016
-4-
availability, assigns resources, sequences jobs, and responds to feedback requests from the other
modules. The operation dispatcher receives requests from the scheduler and generates detailed
operation sequences for the individual machines in the system. Finally, the monitoring object
acts as the cell supervisor and error handler. Glassey and Adiga (1990) present a library of
software objects for control and simulation of manufacturing systems. The primary objective of
this project was to develop a set of simulation modules which simplified the task of assembling
special purpose simulation models customized for individual research questions. The objectoriented paradigm was chosen to provide reuse, extension, and simplified maintenance of the
underlying simulation software. Adiga and Gadre (1990) further illustrate the use of objectoriented programming for modeling FMS. The primary impetus for using object-oriented
modeling, however, is to help in the development of simulations of FMS rather than actual
control systems.
Guo et al. (1990) describe an integrated object-oriented simulation environment for flexible
manufacturing systems. Application specific objects for the system simulations are created
using a class hierarchy. New classes are defined by inheriting the generic features and adding
the implementation specific features. A prototype implementation developed in Smalltalk 80
running under UNIX is described. Kerpelman (1989) describes an object-oriented model of a
manufacturing system used for error diagnosis. The object-oriented software model runs in
parallel to the actual manufacturing system as a real-time simulation. The discrepancies between
the behavior of the model and the behavior of the actual system are used to suggest possible
faults. Narayanan et al., (1992) also describe an object-oriented simulation tool to support
control of manufacturing systems. Mize et al. (1992) describe the modeling of manufacturing
systems using an object oriented approach. This paper includes an extensive discussion of the
justification for and basic principles of object oriented programming and modeling in
manufacturing systems design. One of the goals of this research is to develop a library of objects
for modeling manufacturing systems. Using this library, non-programmers would have the
necessary tools to model their own systems without having to consult modeling experts.
The shop floor controller class described in this paper is designed to fill a similar need to that
of the systems described by Mize et al. (1992) and Narayanan et al. (1992). However, rather
than producing a simulation model, functional shop floor control software is the end result. We
envision the manufacturing engineers being able to build fully operational control systems by
simply “plugging” the individual components together and filling in the implementation-specific
533580448
March 8, 2016
-5-
details. For example, given a manufacturing cell with two CNC machine tools loaded and
unloaded by an industrial robot, the engineer would instantiate three equipment controller objects
and one workstation controller object from the shop floor controller class. These objects would
provide the interfaces and control logic required for integrated control of the cell. The engineer
would use these objects as a starting place and fill in the hardware specific code and the decision
making logic for the particular implementation (as dictated by the production requirements).
Before describing the details of the controller class, we first describe the control architecture
which provides the foundation for the control system.
3. CONTROL ARCHITECTURE
The architecture for a hierarchical system must describe the decomposition of the system
into individual subsystems and provide functional decompositions of these subsystems. The
architecture should also provide the guidelines necessary to develop these subsystems so that
they can be transparently integrated into the larger system. The primary goal of a hierarchal
structure is to develop systems whose subsystems are completely independent so that individual
components can be developed at different locations (e.g. by different vendors) and can be
replaced or updated as necessary without adversely affecting the rest of the system. This has
often been referred to as “plug compatibility,” and has been described extensively in the field of
network communications and in the OSI Reference Model [Pimentel, 1990].
Among existing hierarchical architectures there is much debate over the required number of
distinct levels. We identify three “natural” levels (which are generalized from Joshi et al. (1990)
and Jones and Saleh (1989)): From the bottom of the hierarchy to the top (as shown in Figure 1)
are the equipment, workstation, and shop levels. The equipment level is defined by the physical
shop floor equipment and there is a one-to-one correspondence between equipment level
controllers and shop floor machines. The workstation level is defined by the layout of the
equipment. Processing and storage machines that share the services of material handling
machines and buffer storage space together form workstations. Finally, the shop level acts as a
centralized control and interface point for the system.
These descriptions of each level are virtually identical to those descriptions provided by
Jones and McLean (1986), Jones and Saleh (1989), Simpson et al. (1982), and many others.
However, while these qualitative descriptions of each level provide a conceptual view of the
533580448
March 8, 2016
-6-
hierarchical decomposition, they do not provide the specific detail required to formalize the
control software requirements for control systems based on these architectures. In order to
facilitate software generation (automatic generation, in particular), more detailed descriptions of
the decomposition and of the individual levels are required. Prior to describing these details,
however, we must first present some preliminary material describing the target environment.
3.1. Preliminaries
A part is an individual item that is to be produced by the manufacturing system. While a
part is logically an individual item, it may actually be an assembly or fabrication composed of
other parts. In the production system, each part will have a set of technical attributes which
describe the part and define the required manufacturing operations. These technical attributes
are used to create a process plan for the part. A process plan provides the processing instructions
necessary to produce the part. The representation of a process plan used in this research is a
directed graph that shows the precedence constraints and alternative routings for the part as paths
through the graph (see Figure 2). Each node in the graph represents a specific operation or set of
operations performed by a machine or group of machines. The processing instructions associated
with each operation (e.g., NC files) are assumed to exist. Each arc represents the movement of
the part from the machine or workstation represented by the tail node to the machine or
workstation represented by the head node. Any path from the start node to the end node
represents a valid processing sequence. This representation is a simplified view of those
described by Mettala (1989) and Catron and Ray (1991).
We also introduce the concept of a part group. A part group is a group of parts which is
handled as a single entity. For example, several parts can be attached to a multi-part fixture for
transport and/or processing. In this context, the parts and the fixture together would constitute a
part group. Part groups correspond to the smallest units which are assigned to a controller's
subordinates. For example, consider the case where a pallet of parts is removed from a storage
device, placed on an AGV, and delivered to a workstation for processing. Once at the
workstation, the individual parts are removed from the pallet, processed by the machines in the
workstation, and placed back on the pallet. From the storage system and AGV points of view,
the parts and the pallet together constitute a part group since the parts are not separated from the
pallet. However, from the workstation point of view, they do not constitute a part group since
the parts are removed from the pallet and processed individually. Assemblies are special cases of
533580448
March 8, 2016
-7-
part groups which are not separated (unless rework is required). An important property
illustrated by the assembly and disassembly cases, is that part groups can be dynamically created
and destroyed by different controllers. In its simplest form, a part group is one or more items
being processed, handled, or transported as a unit.
A shop or manufacturing system is comprised of a number of machines. These machines
perform the processing, transportation, inspection, and storage of raw materials, WIP, and
finished goods. Each part is processed on the machines with the system according to the process
plan for that part. The controller class presented in this paper concentrates on the equipment and
workstation levels in the control hierarchy.
3.2. Equipment Level
Within the control hierarchy shown in Figure 1, the equipment level represents a logical view
of a machine and an equipment level controller (see Figure 3). Individual pieces of equipment
also have machine controllers which provide physical control for the devices. These include
CNC controllers, programmable controllers, and other motion controllers and are usually
provided by the machine tool vendors. Equipment controllers provide a standard interface (based
on the equipment type) to the rest of the control system. This interface hides the
implementation-specific code required for machines from different vendors. An equipment level
controller makes decisions regarding local part sequencing, keeps track of part locations, and
monitors the operation of the machine under its control. Equipment is partitioned into material
processors, material handlers, material transportors, and automated storage devices. This
partitioning is based on the equipment behavior. The behavior of a controller is described by the
corresponding message-based part state graph (MPSG) and physical model (Smith,1992). These
models are described in more detail in Section 4.3.
The class of material processors (MP) includes machining centers, inspection devices,
assembly machines, and other devices. The key factor in placing a machine in this class is that
the machine has the ability to autonomously “process” a part in some way as indicated in the
process plan. By “processing,” we mean any activity that results in a change in the information
content associated with the physical state of the part. For example, a turning center, a coordinate
measuring machine, and a painting booth are fundamentally different in terms of their processes,
but from a control point of view, each of these simply processes parts according to some set of
533580448
March 8, 2016
-8-
instructions described by the process plan. A material processor may also have local storage and
a dedicated load/unload device to move parts between the processing area and local storage. For
example many machining centers include a rotating index table or a pallet exchanger which holds
multiple parts. These dedicated load/unload devices are controlled by the same device controller
as the material processor. Based on the capability for local storage, each piece of equipment has
a maximum capacity, indicating the maximum number of parts that can be assigned to that device
at one time. Each unit of the capacity is designated as a location. A location can be addressable
or nonaddressable. An addressable location is reachable by an external device (e.g., a robot or
an operator), whereas a nonaddressable location is reachable only by the material processor
itself.
The class of automated storage machines (AS) is made up of various automated storage and
retreival (AS/R) type devices. A piece of automated storage and retrieval machinery stores raw
materials, work in process, finished parts, tools, and fixtures in locations known to the AS/RS
controller. Storage machines deliver stored objects to a load/unload point and retrieve objects
from (possibly different) load/unload points and place them in storage in response to commands.
Similar to previous machines, automated storage machines have a capacity, which consists of
addressable (load/unload points) and non-addressable (storage) locations. In general, the
capacity of an automated storage device is much greater than the number of addressable
locations.
Machines used for moving objects within the manufacturing shop are separated into two
classes. The class of material handling machines (MH) is made up of robots, indexing devices,
and other devices capable of moving parts from one location to another in a specified orientation.
These locations are typically close together relative to the size of the factory. The primary
function here is to load (unload) parts into (from) various material processors and automated
storage machines. Associated with each piece of material handling equipment is a set of
addressible locations called the reachability set. This set defines the work volume of the device.
If an addressible location belonging to another peice of equipment is in the reachability set of a
material handling device, then the material handling device can load and unload parts on that
device.
The class of material transport machines (MT) is made up of AGV's, conveyors, fork trucks,
and other manual or automated transport machines. The primary function of these machines is to
533580448
March 8, 2016
-9-
transport parts to various locations throughout the factory. The distinction between material
handling machines and material transport machines is that material handling machines can load
and unload other equipment, and material transport machines can not. Typically, material
handling machines perform intra-workstation part movement functions and material transport
machines perform inter-workstation part movement. A specific type of material movement
machine (e.g. a conveyor or a robot) could belong to either class, but within a particular system,
each specific device (e.g. conveyor #8 or the Puma robot) will be considered either a material
handler or a material transporter, but not both. Associated with each material transport device, is
set of ports. A port is a location at which the individual transport device may stop to be
loaded/unloaded. An example of a port is an AGV station where individual AGVs stop to be
loaded and unloaded at a workstation. Each port may contain one or more addressible locations
to account for the case where pallets are delivered by the transport device. An individual port
may be shared by several material transport devices.
To process a part, the equipment follows an equipment level process plan. Each node in the
process plan graph (as shown in Figure 2) represents an operation performed by a specific
equipment level device and contains the information required by the machine to process the part.
In the case of an NC machine tool, this includes the machining parameters such as speeds, feeds,
tool selections, tool paths, and so on. In some cases, an additional decomposition might be
required within the equipment controller to convert the processing instruction data into a form
directly usable by the specific machine controller. For example, if a machine tool controller
requires instructions as CLDATA and the processing instructions data are stored in the form of a
CAD file, a CAD-to-CLDATA conversion would be required. These conversions are performed
by an external function (illustrated as the Convert block in Figure 3) called by the equipment
controller.
3.3. Workstation Level
A workstation is made up of one or more pieces of equipment under the control of a
workstation level controller. Workstations are defined using the physical layout of the
equipment and are generally configured so that multiple MP devices can share the services of
one or more MH devices and/or ports.
533580448
March 8, 2016
-10-
The workstation controller carries out commands received from the shop controller and is
responsible for moving parts between the various pieces of equipment in the workstation and for
specifying part processing performed at this equipment. To this end, it will synchronize the
actions required for coordinating the transfer of parts between processing equipment and material
handling equipment. Since the individual equipment controllers are responsible for sequencing
their tasks once the tasks have been assigned by the workstation controller, the workstation is not
responsible for loading, starting, and monitoring the operation of the machine directly. Instead,
parts are “assigned” to the equipment controller which specifies an addressible location for the
parts. Once the parts have been delivered to the addressible location, they are out of the direct
control of the workstation. At some later time, the equipment controller informs the workstation
controller that the processing of the parts has been completed and provides an addressible
location from which to pickup the parts.
A synchronization may also be required between the material handling equipment and a
material transport device present at a port to deliver or remove parts. This would occur when
parts are transported on fixtured pallets, for example. In this case, the communication required
for the synchronization will be with the shop controller rather than with the material transport
device directly. The shop controller will, in turn, communicate with the transport workstation
through the Resource Manager to facilitate the synchronization.
When a part enters a processing workstation, it follows a workstation level process plan.
This lists the various pieces of equipment in the workstation that the part must be sequenced
across and the order that operations must occur. In the general case, a workstation level process
plan may include alternative routings for a part. Each of these alternate routings can be viewed
as a path through the workstation process plan graph. A workstation level process plan is a
particular view of the equipment process plan which includes only the equipment within the
specific workstation (as shown in Figure 2).
4. CONTROLLER CLASS HIERARCHY
As described by Joshi et al. (1989) and Jones and Saleh (1990), shop floor controllers at all
levels in the hierarchy perform the three functions: planning; scheduling; and execution.
Planning determines what tasks the controllers are going to perform, scheduling determines the
start/finish times for each task, and execution performs the scheduled task. Smith et al. (1992)
533580448
March 8, 2016
-11-
have highlighted the need for explicitly separating these functions within each controller. This
separation allows different planning/scheduling modules to be “plugged into” the execution
module for a particular hardware configuration in response to changes in the production
requirements. In order to perform these functions, controllers must also perform various support
functions such as communications and database functions. These support functions are generic
across all control levels. Similarly, the controllers' user interface is generic in behavior, but
unique in implementation. This characteristic makes it an ideal application for object oriented
techniques. A shop floor controller class hierarchy has been developed to exploit the
similarities in controller operations.
Within a hierarchical control system, individual controllers are essentially “black boxes”
which respond to requests from the upper level controller by partitioning a problem into
independent sub problems and requesting that their subordinates solve the individual sub
problems. In the object oriented paradigm, these black boxes are called objects. In keeping with
the requirements of Naylor and Volz (1986), these objects have well-defined public interfaces
and internals completely hidden from the external world. A class hierarchy can be developed by
successively specializing a base class. Within the hierarchy, a class inherits all of the
functionality of its parent class and adds additional functionality based on the underlying
system's desired behavior.
A block diagram of the shop floor controller class hierarchy is shown in Figure 4. The base
class for the shop floor controller class hierarchy is the storage class, which provides database
functions for accessing and maintaining part information. The controller class extends the
storage class by adding functions that are generic across all controllers. These functions include
the planning, scheduling, and execution functions, as well as the support functions described in
the control architecture. The communications class (which is an embedded class within the
controller class), provides a generic, hardware-independent interface to a set of message passing
functions. The equipment, workstation, and shop classes further specialize the controller class
based on the respective requirements of the equipment, workstation, and shop control levels
within the control architecture. These individual classes will be described in the following
sections.
533580448
March 8, 2016
-12-
4.1. Storage Class
Shop floor controllers control the manipulation of parts, tools, fixtures, etc., within the
manufacturing system. Currently we are concentrating on the part manipulation, but this can
easily be extended to include other items of interest. This manipulation might include transport,
storage, and/or processing, depending on the type of the specific controller. Regardless of the
specific tasks, controllers require database-type functions to keep track of the parts assigned to
the controller. The storage class implements these database functions. The storage class
structure is shown in Figure 5. The storage class includes two related databases: a part database
(Parts) and a slot database (Slots). These databases are related by the part number field (Part)
and the slot number field (Slot). This relationship enforces the requirement that parts assigned to
the controller must be assigned to a slot known to the controller. The interpretation of a slot
depends on the type of the specific controller. For an equipment level controller, a slot
represents a physical location such as a chuck, fixture, or vise at which the part can be located.
For a workstation controller, a slot represents a subordinate entity (e.g. an equipment controller)
to which a part can be assigned. Similarly, for a shop controller, a slot represents a workstation
to which a part can be assigned.
The PART record structure includes fields for the part number (PNum), the part state (State),
the slot to which the part is assigned (Slot), a process plan file name (NCFile), and a parameter
array (Parameter).1 The parameter array is used to store various information, the meaning of
which depends on the level of the controller and the state of the part. For example, while
transferring a part between two pieces of equipment, the part is known to three equipment level
entities: the source entity; the material handling entity performing the transfer; and the
destination entity. At the workstation level, the entity numbers corresponding to these three
entities are stored in the parameter array.
The SLOT record structure includes fields for the index of the part assigned to the slot
(Part), the workstation location for the slot (WkstnLoc), and boolean variables specifying
whether or not the slot is blocked (Blocked), is a processing slot (Processing), and whether or not
the slot requires a synchronization during loading/unloading (Synch). These boolean variables
are used primarily for equipment level controllers. A synchronization is required when the slot
1Additional fields may be necessary for the scheduler. If new fields are added, methods to access these
fields must be provided in the storage class definition.
533580448
March 8, 2016
-13-
has a work-holding mechanism (e.g. a chuck, fixture, or vise) which must be activated when a
part is loaded or unloaded. A slot which is blocked can not be addressed (for loading or
unloading) while the device is running. A slot is a processing slot if parts can be processed while
occupying the slot.
The storage class includes the part and slot databases along with fields for the capacity of the
object (Capacity) and the number of parts currently assigned to the object (NumParts). The
methods for the storage class provide access to the database information. For example, the
getPartState() method returns the current state of the specified part. Similarly, the getSynch()
method returns the boolean variable specifying whether the specified part requires a
synchronization to be loaded or unloaded (based on the slot to which the part is assigned). The
class methods hide the details of the data structure implementation. For example, by accessing
the part state using the setPartState() and getPartState() methods, the calling programs will be
unaffected by changes to the internal part database structure.
4.2. Communications Class
In a distributed environment, control is exercised by passing messages between controllers.
In a non-homogeneous environment (in terms of computer hardware and software), developing
transparent message passing is a non-trivial task. Within a controller the Communications
Module performs these functions. The Communications Module is an object instantiated from
the communications class. The communications class provides data structures and methods
which implement a generic, hardware-independent interface to a set of message passing
functions. The communications class description is shown in Figure 6. The MESSAGE
structure includes fields for the text message (Message), message source (Source), and message
length (Length). This structure is used to store incoming messages for use by other modules of
the controller. The communications class includes an array of messages (In), a port number field
(Port), an in-message counter field (NumIn), and a port-initialized flag (PortInitialized). The
class includes methods to initialize the port, close the port, send and receive messages, check for
messages, and wait for messages.
In order to create a communications object for a specific hardware configuration (e.g., serial
point-to-point or network communications), the checkMessages(), portInit(), sendMessage(), and
portClose() methods must be modified to accommodate the specific hardware. For example, the
533580448
March 8, 2016
-14-
checkMessages() method checks the port and, if messages have arrived, reads the messages into
the message queue. The implementation of this method requires a device-specific function to
check the port and return any characters that have been read. The generic portion of the method
will then convert the string of characters into individual messages and insert these messages into
the message queue. The remaining methods (getMessage(), waitForMessage(), and
forcedInMessage()) are generic. These methods require modification only when the message
data structure is modified. The device-specific class methods have been implemented using
asynchronous serial communications for DOS and OS/2, TCP/IP over an ethernet network for
DOS, OS/2, ULTRIX, an dAIX, and through interprocess communication on OS/2. Through the
use of this class, the controller is completely unaware of the physical connection to the rest of the
shop, and it can be easily moved between computers and operating systems if necessary.
4.3. Controller Class
The controller class inherits the database structures and methods from the storage class and
adds data structures and methods necessary for implementing generic shop floor controllers. The
controller class definition is shown in Figure 7. A controller is essentially a storage system
which exhibits a specific behavior. Parts are stored within the domain of the controller while
processing is performed. At the equipment level, the domain is the physical device itself. At the
workstation level, the domain includes the set of equipment comprising the workstation. At the
shop level, the domain includes the entire shop. Therefore, every part will simultaneously exist
within three domains: the shop, a workstation within the shop, and a particular piece of
equipment within that workstation.
The behavior of the controller is implemented by sending and receiving messages and
interacting directly with shop floor equipment. The features added to the storage class include a
communications object (Comm) for communicating with the supervisory controller, a command
object (Input) for processing input messages, and a message-based part state graph object
(MPSG) for implementing the MPSG which defines the controller behavior (described below).
Note that the class definition does not include communications objects for the subordinate
systems. Instead these objects are included in the derived classes for equipment, workstations,
and shops, since each has different requirements for communicating with subordinates.
533580448
March 8, 2016
-15-
An MPSG describes the behavior of a controller in terms of the messages that it accepts, the
messages that it sends and the physical actions that it performs (Smith, 1992). The MPSG model
provides a formal, implementation-independent model for describing system behavior in terms of
messages and actions. These messages and actions are termed the processing protocol for the
controller. An MPSG models the processing protocol as a finite state machine in which the state
represents the processing state of the part and the transitions are caused by receiving or sending
messages or performing controller actions. MPSGs for generic MP, AS, MH, and MT
equipment have been developed as part of the controller class hierarchy. The a complete
description of the MPSG model is provided by Smith (1992). Our interest here is in a higher
level description of the behavior or a controller. One particular view of an MPSG, the physical
model, provides this description.
A single physical model task represents a defined sequence of messages and actions required
to perform the task. For example, consider the physical models for the four equipment classes
described in Secition 3.2 (as shown in Figure 8). In the MP case, mp_put is a physical model
task representing loading a part on a machine tool with a robot. Within the MPSG, the mp_load
task is expanded into the specific sequence of messages passed between the robot, machine tool,
and workstation controller to synchronize the task. The physical models for the individual
equipment and workstation classes are provided in the following sections. Given any piece of
shop floor equipment and the MPSG describing it's behavior, the C++ source code for the
execution portion of the corresponding controller can be automatically generated. This source
code represents a series of methods within the controller class. A complete description of the
MPSG model and the associated physical models can be found in (Smith, 1992).
The command object (Input) separates a message (or any line of text) into its individual
components. This class provides methods to separate a string into individual tokens, count the
number of tokens, and return requested tokens. The commandParser() method accepts incoming
messages from the communication object, sends the messages to the command object for parsing,
and determines the correct action to perform. The methods addTask() and removeTask() add and
remove controller tasks from the task list. readCommand() scans the console and the supervisors
communication object (Comm) for incoming commands. The doTasks() and doInMessages()
methods are used by the MPSG driver. The virtual methods planner(), scheduler(), and
executor() implement the planning, scheduling, and execution functions, respectively, for each
533580448
March 8, 2016
-16-
controller. These methods are dynamically bound to the object at link time for maximum
flexibility.
There are no “controller objects” within the control system. Instead, the controller class
serves only as a base class and must be further extended using the attributes of the system to
create usable components. The controller class simply serves as a starting point for the
equipment, workstation, and shop classes. These classes are described in the following sections.
4.4. Equipment Class
The equipment class adds equipment level-specific data structures and methods to the
controller class. The equipment class is shown in Figure 9. The class includes data structures
for the equipment name (Name), number (Number), and state (State), along with the methods for
accessing the stored data. The equipment class also includes a communications object (Device)
for communicating with the machine under the control of the equipment controller. This
communications object provides the link between the shop floor equipment and the control
system. The readDescr() method reads the description of the specific piece of equipment (the
description is stored in a text file).
As with the base controller class, there are no actual “equipment objects” within the control
system. Instead, the equipment functionality is inherited to a set of more specific equipment
controllers. Currently four equipment sub-classes have been developed: material processors
(MP), material handlers (MH), material transporters (MT), and automated storage devices (AS).
Each of these classes of equipment has a distinct behavior described by its physical model. The
physical models for these equipment classes are shown in Figure 8. Physical models are finite
state machines in which the states completely define at any point the tasks which have been
performed and the tasks which are allowable at that point. State transitions represent physical
model tasks which are specified by the scheduler and performed by the execution module.
MP class equipment includes NC machine tools, coordinate measuring machines, robotic
welders, and other equipment which processes parts according to a set of instructions. The
physical model specifies that parts are loaded on the equipment (put) , processed (process) , and
unloaded (pick). After loading the part, the processing instructions (e.g., an NC file) can
optionally be downloaded (download) to the physical device prior to processing. AS equipment
consists of automated storage and retrieval systems where parts are placed and stored for
533580448
March 8, 2016
-17-
unspecified lengths of time. The physical model shows that parts are first loaded on the
equipment (load), then are optionally stored (store). If the parts have been stored, they must be
retrieved (retrieve) prior to being unloaded (unload).
MH class equipment includes industrial robots and other pick and place devices which pick
up parts from one location and put them down in another in a defined orientation. MT class
equipment includes automated guided vehicles (AGVs), conveyors, and other equipment which
transports parts between locations. The distinction between MH and MT equipment is that MH
equipment picks up, moves, and places parts, while MT equipment simply moves parts which
have been placed on the equipment by some other device. For example, moving a part from one
processing machine to another typically involves picking the part from the source machine using
an MH device, placing the part on an MT device for transport, picking the part off the MT
device using another MH device, and loading the part on the destination processing machine.
4.5. Workstation Class
The workstation class adds workstation level-specific data structures and methods to the
controller class. A workstation is made up of one or more equipment level systems, each of
which has its own equipment level controller. The task of the workstation controller is to
facilitate the transfer of parts between these individual equipment level systems which perform
the processing/transport/storage functions. In order to perform this task the workstation needs
access to various data associated with each subordinate. This data is stored in an ENTITY
object. The ENTITY class definition is shown in Figure 10. An ENTITY includes data
structures for the entity type (Type), name (Name), part capacity (Capacity), and the number of
parts currently assigned to the entity (NumAssigned). It also includes an array containing the
workstation slots which are assigned to the specific entity (SlotNums). The class definition also
includes the methods to access these data structures. Since entities model equipment level
devices, each entity will also require a communications channel with the associated equipment
controller. The IOChannel (a communications object) provides this communications channel.
The workstation class (shown in Figure 10) includes a data structure for the name of the
workstation (Name) and an array of ENTITY objects (Ents). The integer NumEntities identifies
the number of entities in the array. Each ENTITY object in this array represents one of the
subordinate equipment level systems. The workstation class also includes the methods for
533580448
March 8, 2016
-18-
accessing the data structures. The class also includes the commandParser(), genInputComand(),
processForcedMessage(), processForcedSch(), readDescr(), and tSch() methods described
above.
An example workstation and the associated physical model is shown in Figure 11. This
workstation includes two NC machine tools, a part storage buffer, a conveyor stop, and an
industrial robot for moving parts between the individual pieces of equipment. The physical
model specifies that parts arrive at the workstation via the conveyor (arrive). From the conveyor
port, parts can either be picked up by the robot (port_pick), or depart from the workstation on the
conveyor (depart). Once a part has been picked up by the robot, it can be loaded on either of the
NC machines, the buffer, or back on the conveyor (port_, mp_, or bp_put). Similarly, once the
part has been loaded on one of the equipment level devices, it can be picked back up (mp_, bs_,
or port_pick). This workstation physical model is used to generate the sytem graph, which is a
part contact state graph that includes the probper preconditions for performing system tasks
(Mettala, 1989).
5. IMPLEMENTATION EXPERIENCE
Figure 12 illustrates the development methodology for shop floor controllers. The controller
class provides the basic data structures and interface components described int the previous
sections. The specific class (MP, MH, MT, AS, Workstation, or Shop) depends on the controller
that is being created. The MPSG.M file is the textual representation of the controller’s MPSG.
This file is the primary input to the MPSG Builder which generates the C++ code for recognizing
the processing protocol described by the MPSG. The Task builder is used to interactively create
the task action functions for the controller. The Task Action functions are the low-level,
implementation-specific code required for each piece of equipment. This code can often be
acquired from the equipment vendor. The Scheduler Builder is used to create the scheduler for
the controller. As shown in the diagram, the production requirements are one of the inputs
required to construct at scheduler. The resulting C++ code is compiled and linked with the
MPSG library to create an operational controller. Currently, the Controller Class and the MPSG
Builder have been implemented and are being used, while the Task Actions and the schedulers
are being written by hand.
533580448
March 8, 2016
-19-
Controllers based on this class hierarchy have been developed for use in two separate
laboratories with different equipment configurations: one at the Penn State CIM lab, and the
other at the Texas A&M Computer Aided Manufacturing lab (see Table 1 for a list of the
specific equipment in these labs). For the Penn State lab, this represents the fourth generation of
control software which has been developed in-house. The first two generations were developed
completely by hand coding. The third generation was the first attempt at using automatic code
generation tools (Mettala, 1989). The current implementation combines the automatic gode
generation tools with the shop floor controller class described in this papper. Significant coding
time saving have been achieved over previous generations (Smith 1992).
This represents the first generation of control software for the Texas A&M lab (TAMCAM).
This lab is illustrated in Figure 13. In this lab, the Shuttleworth controller runs on an OS/2-based
personal computer and the remaining equipment level controllers run on DOS-based personal
computers. The workstation and shop controllers run on an IBM RS/6000 workstation. Each
equipment controller includes a direct connection to the corresponding machine controller
through a serial port or a digital I/O board. The equipment, workstation, and shop controllers are
connected using TCP/IP through an ethernet network. A more detailed description of this lab,
the parts produced in the lab, and the control software which runs the lab is provided on the
TAMCAM World Wide Web (WWW) home page at the URI
http://tamcam.tamu.edu/tamcam.html.
Regardless of the fact that very little identical equipment was used between the two labs, the
shop floor controller class has provided a significant opportunity for reusing existing control
software with minimal recoding required. By using the classes as a foundation for controller
development, the user is freed from the tedious tasks associated with integration and enabling
distributed communication between processes. Instead, he/she is free to concentrate on the
operational aspects of the system and the decision-making functions associated with part and
operation sequencing. Furthermore, when the control system requires modification or is ported
to a new operating system, there is a well defined methodology for making the software changes.
6. CONCLUSIONS
A shop floor controller class hierarchy has been presented. The classes within this hierarchy
have been designed to exploit the similarities of the control requirements across and within
533580448
March 8, 2016
-20-
multiple levels in the control architecture. The primary purpose of this class hierarchy is to
simplify the software development for shop floor control systems for automated flexible
manufacturing systems. The software has been successfully implemented within two separate
laboratories, and has achieved tremendous savings in software development time. Work is
continuing at expanding the class to include more complex multi-purpose equipment types and
hybrid control architectures.
The next logical step in this work is to turn our attention to the planning/scheduling problems
associated with automated manufacturing systems. While these problems have been the subject
of much research recently, there is very little implementation experience reported. Instead, most
results are acquired through simulation and other approximation techniques. By using the
controller class to instantiate operational controllers, different planning and scheduling
techniques can be tested using the actual execution code or a high fidelity simulation.
ACKNOWLEDGEMENTS
This work was partially supported through National Science Foundation (NSF) awards
DDM-9009270 and DDM-9158042, both awarded to Dr. Sanjay Joshi and by DARPA grant
ARPA #8881 awarded to Dr. Richard Wysk, Dr. Sanjay Joshi, and Dr. Dennis Pegden.
REFERENCES
Adiga, S. and Gadre, M., Object-Oriented Software modeling of a Flexible Manufacturing
System, Journal of Intelligent and Robotic Systems, Vol 3, 1990, pp. 147-165.
Basnet, C. B., Farrington P. A., Pratt, D. B., Kamath M., Karacal, S. C. and Beaumariage, T. G.,
Experiences in Developing an Object-Oriented Modeling Environment for Manufacturing
Systems, Proceedings of the 1990 Winter Simulation Confrence, 1990, pp. 477-481.
Booch, G., Object-Oriented Design with Applications, Benjamin/Cummings Publishing, 1991.
Booch, G., Object-Oriented Development, IEEE Transactions on Software Engineering, Vol. SE12, No. 2, February 1986, pp. 211-221.
Catron, B.A., and Ray, S.R., "ALPS: A Language for Process Specification," International
Journal of Computer Integrated Manufacturing, Vol. 4, No. 2, pp. 105-113, 1991.
Chaar, J. K., A Methodology for Developing Real-Time Control Software for Efficient and
Dependable Manufacturing Systems, Ph.D. Thesis, University of Michigan, 1990.
Coad, P. and Yourdon, E., Object-Oriented Analysis, Prentice Hall, Englewood Cliffs, NJ, 1991.
533580448
March 8, 2016
-21-
Glassey, C. R. and Adiga, S., Berkeley Library of Objects for Control and Simulation of
Manufacturing (BLOCS/M), Applications of Object-Oriented Programming, Pinson, L. J. and
Wiener, R. S. (eds.), Addison-Wesley, Reading MA., 1990.
Guo, D., Norrie, D. H., and Fauvel, O. R., Object-Oriented Flexible Manufacturing System
Simulation, The Proceedings of the 1990 Summer Computer Simulation Confrence, Calgary,
Alberta, Canada, July 1990, pp. 225-230.
Hadj-Alouane, N. B., Chaar, J. K., and Naylor, A. W., The Design and Implementation of the
Control Software of the Prismatic Machining Cell, Center for Research on Integrated
Manufacturing, The University of Michigan, Ann Arbor, MI. 1990.
Jones, A. T. and McLean, C. R., A Proposed Hierarchical Control Architecture for Automated
Manufacturing Systems, Journal of Manufacturing Systems, Vol. 5, No. 1, 1986, pp. 15-25.
Jones, A. and Saleh, A., A Decentralized Control Architecture for Computer Integrated
Manufacturing Systems, IEEE Symposium on Intelligent Control, 1989, pp. 44-49.
Joshi, S. B., Wysk, R. A., and Jones, A., A Scaleable Architecture for CIM Shop Floor Control,
Proceedings of CIMCON '90, A. Jones Ed., National Institute of Standards and Technology, May
1990, pp. 21-33.
Kerpelman, D. T., Object-Oriented Model-Based Reasoning for Diagnosing Automated
Manufacturing Systems, IEEE Symposium on Intelligent Control, 1989, pp. 703-708.
Maimon, O. Z. and Fisher, E. L., An Object-Based Representation Method for a Manufacturing
Cell Controller, Artificial Intelligence in Engineering, Vol. 3, No. 1, 1988, pp. 2-11.
Mettala, E. G., Automatic Generation of Control Software in Computer Integrated
Manufacturing, Ph.D. Thesis, The Pennsylvania State University, 1989.
Mize, J. H., Bhuskute, H. C., Pratt, D. B., and Kamath, M., Modeling of Integrated
Manufacturing Systems Using an Object-Oriented Approach. IIE Transactions, Vol. 24, No. 3,
1992, pp. 14-26.
Narayanan, S., Bodner, D. A., Mitchell, C. M., McGinnis, L. F., Govindaraj, T., and Platzman, L.
L., Proceedings of the 1992 Western Multiconference , Society of Computer Simulation,
Newport Beach, CA, January 1992, pp. 59-63.
Naylor, A. W. and Maletz, The Manufacturing Game: A Formal Approach to Manufacturing
Software, IEEE Transactions on Systems, Man and Cybernetics, Vol. SMC-16, pp. 321-224,
May/June 1986.
Naylor, A. W. and Volz, R. A., Design of Integrated Manufacturing Control Software, IEEE
Transactions on Systems, Man, and Cybernetics, Vol. SMC-17, No. 6, November/December
1987, pp. 881-897.
O'Grady, P. and Seshadri, R., X-Cell - Intelligent Cell Control Using Object-Oriented
Programming (Part I), Computer Integrated Manufacturing Systems, Vol. 3, No. 4, August 1991,
pp. 157-163.
533580448
March 8, 2016
-22-
Pimentel, J. R., Communication Networks for Manufacturing, Prentice-Hall, Englewood Cliffs,
NJ, 1990.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W., Object-Oriented
Modeling and Design, Prentice Hall, Englewood Cliffs, NJ, 1991.
Shaw, M. J., Solberg, J. J., and Woo, T. C., System Integration in Intelligent Manufacturing: An
Introduction. IIE Transactions, Vol. 24, No. 3, July 1992, pp. 2-6.
Simpson, J. A., Hocken, R. J., and Albus, J. S., The Automated Manufacturing Research Facility
of the National Bureau of Standards, Journal of Manufacturing Systems, Vol. 1, No. 1, 1982, pp.
17-31.
Smith, J. S., A Formal Design and Development Methodology for Shop Floor Control in
Computer Integrated Manufacturing, Ph.D. Dissertation, The Pennsylvania State University,
University Park, PA 16802, 1992.
Smith, J. S. and Joshi, S. B., Reusable Software Concepts Applied to the Development of FMS
Control Software. International Journal of Computer Integrated Manufacturing, Vol. 5, No. 3,
1992, pp. 182-196.
Smith, J. S., and Joshi, S. B., Message-based Part State Graphs (MPSG): A Formal Model for
Shop Floor Control, Penn State University Working Paper Series, University Park, PA, 1993.
533580448
March 8, 2016
Table 1. Equipment list for the Penn State and Texas A&M CIM laboratories.
Equipment
Class
Description
MP
CNC turning center, FANUC
Name
Penn State
Lab
Fanuc Puma 6
controller
Pratt &
MP
Whitney Horizon V
3 Axis horizontal machining
center
Bridgeport
MP
3 Axis vertical milling machine
Kardex
AS
Vertical warehouse
GMF-M1L
MH
Cylindrical robot
IBM 7545
MP
SCARA robot (assembly
Industriever
operations)
IBM 7535
MH
SCARA robot
Fanuc A0
MH
Articulated robot
SI Mini Cartrac
MT
Cart-based conveyor system
MP
3 axis vertical machining center
MP
4 axis vertical machining center
Leadwell XT
MP
Turning center
Kardex
AS
Vertical warehouse
MH
SCARA robot
Texas A&M
Lab
Pratt &
Whitney Drill-omatic
Cincinnati
Milacron Sabre 500
11
Industriever
Adept One
-23-
533580448
March 8, 2016
Puma 760
MH
Articulated robot
G.E. A4
MH
SCARA robot
Shuttleworth
MT
Smart conveyor
-24-
Shop
Wkstn
Equip
Wkstn
Wkstn
Equip
Equip
Equip
Equip
Equip
Figure 1. Three-level hierarchical control architecture.
Equipment level process plan graph
E7
E2
E5
E1
E8
E3
E4
E10
E6
E9
Workstation Configurations:
W1: E1
W2: E3 + E4
W3: E2 + E5
W4: E6 + E9
W5: E7 + E8 + E10
Workstation level process plan graph
W3
W1
W5
W2
W4
Figure 2. Process plan representation.
533580448
March 8, 2016
-25-
Workstation
Controller
Equipment process
plan (e.g. CAD file).
Equipment
Controller
Convert
Device specific data
(e.g. NC file, CLDATA, etc)
Device
Controller
Individual spindle/joint
activation sequences
Physical
Device
Figure 3. Equipment level controller.
Storage
Controller
Workstation
Processing
Transport
Shop
Storage
Equipment
MP
AS
Figure 4. Shop floor controller class.
MH
MT
533580448
March 8, 2016
// storage.h - ASRS Class definitions
// Part reference definition.
typedef struct {
char PNum[PartNumLength+1];
// Part number
int State;
// MPSG state
int Slot;
// Slot index
int Parameter[3];
// In-message parameter array
int DueDate;
// Part due date
int *NCFile;
// process plan file
} PART;
// Storage slot definition.
typedef struct {
int Part;
// Part Number
int WkstnLoc;
// Workstation location index for the part
char Synch;
// Is a synch required ?
char Blocked;
// Can the slot be accessed while the m/c is running
char Processing;
// Is this a processing location ?
} SLOT; // Storage slot
// STORAGE class
class STORAGE {
protected :
int
Capacity;
// capacity of the STORAGE device
SLOT *Slots;
// Slot array
PART *Parts;
// Parts array
int
NumParts;
// number of parts currently assigned.
public :
STORAGE()
{ Capacity = 0; NumParts = 0; }
~STORAGE();
int getCapacity()
{ return(Capacity); }
int getNumParts()
{ return(NumParts); }
int getPartLocation(int PartIndex);
int getPartState(int Index);
int setPartState(int Index, int PartState);
int getPartParam(char *PartNum, int ParamNum);
void setPartParam(char *PartNum, int ParamNum, int Param);
int getDueDate(char *PartNum);
int setDueDate(char *PartNum, int DDate);
int getSynch(int PartIndex);
int getBlocked(int PartIndex);
int getProcessing(int PartIndex);
virtual void setCapacity(int Cap);
};
Figure 5. Storage class definition
// comm.h - Communications module definitions
// Internal Message Structure
typedef struct MESSAGE {
int Source;
int Length;
char *Message;
} MESSAGE ;
// Communications Class
class CommClass {
int NumIn;
int Port;
MESSAGE In[MAX_IN_MESSAGES];
int PortInitialized;
public :
CommClass(void);
void portInit(int PortNum);
void portClose();
int inCount() { return(NumIn); }
int getMessage(char *Mess, int MaxLen);
int checkMessages();
void sendMessage(char *Mess);
int waitForMessage();
void forcedInMessage(char *Mess);
};
Figure 6. Communications class.
-26-
533580448
March 8, 2016
-27-
// Controller class definition
class CONTROLLER : public STORAGE {
protected:
int Type;
// Shop, Workstation, Equipment
int ControllerPort;
TASK_ITEM *Tasks;
public:
CONTROLLER() { Type = 0; };
CONTROLLER(int ContType) { Type = ContType; };
CommClass
Comm;
COMMAND
Input;
MPSG_DEF
MPSG;
int
readCommand();
void
removeTask(int TaskNum);
void
showTasks();
void
setCapacity(int Cap);
void doTasks();
virtual void doInMessages(int MessageNumber);
virtual int removePart(int PIndex);
virtual void planner();
virtual void scheduler();
virtual void executor();
} ;
Figure 7. Controller class.
download
download
mp_put
process
mp_pick
MP:
pick
put
MH:
store
AS:
MT:
retrieve
as_put
as_pick
port_put
move
port_pick
Figure 8. Equipment level physical models.
533580448
March 8, 2016
// Equipment Class definitions
class EQUIPMENT : public CONTROLLER {
char *Name;
int Status;
int State;
int Number;
public :
EQUIPMENT(int T, char *N, int Num);
EQUIPMENT()
{Name = NULL;}
CommClass Device;
void setType(int T)
{Type = T;}
int getType()
{return(Type);}
void setName(char *N)
{Name = strdup(N);}
char *getName()
{return(Name);}
void setStatus(int S)
{Status = S;}
int getStatus()
{return(Status);}
void setState(int S)
{State = S;}
int getState()
{return(State);}
void setNumber(int N)
{Number = N; }
int getNumber()
{return(Number);}
int commandParser();
void readDescr(char *FName);
void processForcedSch();
};
Figure 9. Equipment class
// wkstn.h - workstation class definition file
class ENTITY {
protected :
int Type;
char *Name;
int Capacity;
int *SlotNums;
int NumAssigned;
public :
ENTITIES();
CommClass *IOChannel;
void setName(char *EName)
{Name = strdup(EName);}
char *getName()
{return(Name);}
void setType(int EType)
{Type = EType;}
int getType()
{return(Type);}
void setCapacity(int Cap);
int getCapacity()
{return(Capacity);}
} ;
class WORKSTATION : public CONTROLLER {
protected :
char *Name;
int Num;
int MHEntity;
public :
ENTITY *Ents;
int NumEntities;
void setName(char *N);
char *getName()
{return(Name);}
void readDescr(char *Fname);
void setNumEntities(int Num);
int getNumEntities() {return(NumEntities);}
int getInputCommand();
void partArrive(int MessageNumber);
int assignPartToEntity(int PIndex, int ENum);
void processForcedMessage();
void processForcedSch();
void doInMessages(int MessageNumber);
void whichEntity(int PartIndex);
};
Figure 10. Workstation class.
-28-
533580448
March 8, 2016
-29-
MP
E
Horizon V
Vertical Mill
mp_put
mp_pick
port_depart
Material
Transport
Cart
mp_pick
port_pick
Daewoo
Puma
Turning
Center
Fanuc M1-L
Buffer
Port
MH
MP
port_put
mp_put
port_arrive
bs_pick
bs_put
S
BS
Figure 11. Workstation configuration and associated physical model.
Figure 12. Controller generation methodology.
533580448
March 8, 2016
-30-
Pratt & Whitney
(MP1)
DOS PC
Adept
(MH1)
Port
(P1)
DOS PC
DOS PC
Leadwell
(MP2)
Manual Wkstn 1
(OP1)
Sabre 500
(MP3)
GE-A4 (MH3)
DOS PC
DOS PC
DOS PC
Manual Wkstn 2
(OP2)
Port
(P3)
Puma 760 (MH2)
Port
(P2)
DOS PC
Kardex
(AS1)
Shuttleworth
(MT1)
OS/2 PC
TAMU Ethernet
Backbone
IBM RS/6000
Shop Controller
IBM RS/6000
Design Workstation
Figure 13. Texas A&M Computer Aided Manufacturing lab.