To appear in SPIE Volume 2913, Proceedings of Plug and Play Software for Agile Manufacturing, Boston,

Massachusetts, November 18-19, 1996.

Using CORBA to integrate manufacturing cells to a virtual enterprise

Carmen M. Pancerella ( carmen@sandia.gov)
Robert A. Whiteside (raw@sandia.gov)
P.O. Box 969, Mailstop 9012, Sandia National Laboratories, Livermore, CA 94551-0969

ABSTRACT
It is critical in todays enterprises that manufacturing facilities are not isolated from design, planning, and other
business activities and that information flows easily and bidirectionally between these activities. It is also important and
cost-effective that COTS (commercial-off-the-shelf) software, databases, and corporate legacy codes are well integrated in
the information architecture. Further, much of the information generated during manufacturing must be dynamically
accessible to engineering and business operations both in a restricted corporate Intranet and on the Internet.
The software integration strategy in the Sandia Agile Manufacturing Testbed supports these enterprise requirements.
We are developing a CORBA-based distributed object software system for manufacturing. Each physical machining
device is a CORBA object and exports a common IDL interface to allow for rapid and dynamic insertion, deletion, and
upgrading within the manufacturing cell. Cell management CORBA components access manufacturing devices without
knowledge of any device-specific implementation. To support information flow from design to planning to
manufacturing, an electronic traveler, itself a persistent CORBA object, has been developed. Thus, design and planning
data is accessible to machinists on the shop floor.
CORBA allows manufacturing components to be easily accessible to the enterprise. Dynamic clients can be created
using web browsers and portable Java GUIs. A CORBA-OLE adapter allows integration to PC desktop applications.
Other commercial software can access CORBA network objects in the information architecture through vendor APIs.
Keywords: distributed objects, CORBA, agile manufacturing, enterprise integration, information architectures.

1. INTRODUCTION
Increasing competitiveness in manufacturing worldwide has spurred efforts to increase production flexibility and
permit rapid setup for smaller lot sizes. Agile manufacturing [8] must support changes in product mix, batch size,
manufacturing processes, customer requirements, and technology and at the same time provide cost-effectiveness, reduced
cycle times, and high quality and accuracy.
An agile manufacturing facility imposes special requirements including support for human interaction with
machining devices, plug-and play of manufacturing devices with little to no downtime in service, ease of upgrading
machine controllers, and information flow into and out of manufacturing devices. Further, this facility itself must allow
for information to dynamically flow both to and from design environments, planning environments (fabrication,
inspection, and assembly), and other business services in an extended enterprise, both within a corporate Intranet and on
the Internet. In practice, the enterprise may span geographic, organizational, and possibly international boundaries;
hence, it is most often heterogeneous with respect to computer platforms, operating systems, network capabilities, and
custom and commercial software.
A robust software architecture is key to achieving agility and to realizing the integration of the extended enterprise.
This information architecture must be scaleable, interoperable, and reconfigurable. Internet technology, web browser
technology, electronic data exchange, and industry standards for interoperability will be core to the infrastructure. It
comes as no surprise that the February 1996 Communications of the ACM devoted an entire issue to the growing role of
computer science and software in manufacturing [14].

This work was supported by Sandia Corporation under Contract No. DE-AC04-94-AL85000 with the U.S. Department of Energy.

1.1 Sandia Agile Manufacturing Testbed

The Sandia Agile Manufacturing Testbed (SAMT) [9] is a manufacturing research facility at Sandia National
Laboratories in Livermore, California. The project objective is to develop agile manufacturing processes for various
machined and welded products.
The physical component in the SAMT is a networked manufacturing cell containing a conventional milling machine
(Cincinnati 4-axis mill), a milling machine equipped with an open architecture controller (Haas 4-axis mill), a lathe, a
gas tungsten arc welder, a coordinate measuring machine (CMM), various storage devices, and a Stubli robot which
services some of the manufacturing and storage devices. Each of the manufacturing devices (lathe, milling machines,
CMM, welder) has a computersometimes sharedwhich has two functions:

as a network connection to the machine controller, allowing programs and control commands to be downloaded
and executed in an automated fashion, and

as an operator console for electronic data to be delivered to the shop floor in support of manual operations, e.g.,
machine setup, or as a guardian interface [11].

The computers in the manufacturing cell include both PCs and Sun workstations.
The cell management activities include scheduling, tracking, and job dispatching to the shop floor. The cell
management software and machine operators need access to design and planning data. Furthermore, information from
fabrication and inspection must be stored, analyzed, and accessible to designers and process engineers at a later time. An
underlying objective of the cell management software is information-driven manufacturing, that is, to first automate the
flow of information to facilitate all those processes which precede and follow the actual machining of a part. Where it
makes sense, the cell management software will also permit the automation of the machining itself.

1.2 Common Object Request Broker Architecture (CORBA)

CORBA [4] is an industry middleware standard for building distributed, heterogeneous, object-oriented applications.
CORBA is specified by the Object Management Group (OMG), a non-profit consortium of computer hardware and
software vendors. At this time, CORBA provides the best technical solution for integrating our manufacturing testbed; it
is open, robust, heterogeneous, interoperable, multiplatform, and multivendor supported.
The OMG Interface Definition Language (IDL) is used to define interfaces in CORBA. An IDL interface file
describes the data types, and methods or operations that a server provides for an implementation of a given object. IDL is
not a programming language, but rather a language that describes only interfaces: there are no implementation-related
constructs in the language. The OMG does specify mappings from IDL to various programming languages including C,
C++, and Smalltalk. We will use IDL throughout this paper to show our interfaces to manufacturing devices, the task
sequencer, and other CORBA objects in our system. Our particular manufacturing object implementations have all been
written in C++, and our ORB product is Orbix from IONA Technologies.
The Internet Inter-ORB Protocol (IIOP) is part of the CORBA 2.0 specification; it is an open Internet protocol for
connecting large distributed applications across the Internet. Specifically, it provides for ORB-to-ORB communication
built on top of TCP/IP. IIOP can connect applications running on different computers and is scaleable from the LAN to
the Internet.

2. SOFTWARE INTEGRATION STRATEGY

Given the requirement for agility, the heterogeneous computing resources, and the need to connect to an extended
enterprise, there are several demands placed on software in the SAMT. Specifically, the software must support a variety
of platforms, operating systems, and programming languages. It must support rapid and easy customization, integration,
and reconfiguration. The software must facilitate information flow through the product realization cycle from design
and analysis to planning to fabrication and inspection. The software must be easy to deploy and usable throughout
engineering and manufacturing facilities. Finally, the manufacturing cell must be easily integrated into the extended
enterprise such that manufacturing process data (for example, inspection reports and on-machine measurements) can be

stored in a database for use by designers and process engineers in the future. In this section, we discuss some of our
design goals, and show how the use of CORBA provides a solution for integrating a manufacturing enterprise.

2.1 Integrating CAD systems and COTS software

Currently at Sandia, most mechanical designers use Pro/ENGINEER from Parametric Technology Corporation.
Pro/DEVELOP is a software developers toolkit with a C API for allowing Pro/ENGINEER to access other applications.
Through this API, a designers standard interface can be customized to be a client to any CORBA object in the enterprise.
Further, certain Pro/ENGINEER tasks that execute at a command line, for example, the translation of a Pro/ENGINEER
file to another supported output file type, can be wrapped as an object, which is accessible over the network. We have
successfully created a CORBA object which translates a Pro/ENGINEER part file into a VRML file; the implementation
of this translator object uses a command line call to Pro/ENGINEER, returning an SGI Open Inventor file, which is then
translated to VRML with another translator. The three-step translation, including the use of Pro/ENGINEER, is
transparent to any client.
Similarly, we have wrapped a product data management (PDM) system, specifically WorkGroup Technology
Corporations CMS, as a CORBA object. The implementation of the PDM object uses C API calls to CMS, allowing the
functionality of CMS to be exposed to other applications on a network. The CORBA object interface to the PDM allows
meta-data to be changed, and documents to be checked in and out of the PDM. The PDM CORBA object is key to the
implementation of our electronic traveler (Section 4.), where manufacturing data, user inputs, inspection reports, and any
related files can be attached to a traveler, and the traveler itself will be archived in the PDM. Our CORBA-based
manufacturing cell software can access a PDM CORBA object on the network, possibly off-site; thus, machining data,
inspection reports, welding information, and operator forms can be entered automatically into the PDM without a user
entering this data through the standard CMS GUI.
Any commercially available software packages which has an API can be wrapped with a CORBA interface and made
available on the network. Further, any COTS package which has an extensible GUI can be extended to be a CORBA
client.

2.2 Integrating legacy software and databases

In a manufacturing enterprise, it may be necessary to integrate legacy codes into a design or manufacturing
environment. In our design environment, we had several legacy design and analysis codes written in FORTRAN. These
particular codes were solid engineering codes, yet they didnt execute because the I/O required an old graphics terminal.
CORBA provided a solution to making this code accessible again, without having to rewrite the code. First, we stripped
out any I/O from the source code, and created a library, which could be called from C or C++ code. Second, we defined a
CORBA IDL to the code, providing functionality for putting data into the analysis code, executing any engineering
functions, and extracting data from the analysis code. This software component then becomes available over the network
to clients developed in many ways. (In Section 2.3, we discuss a number of methods for developing client software to
CORBA objects.) A new graphical user interface to the code can be developed easily without changing the engineering
functionality in the analysis code.
We use the same approach for wrapping relational databases as CORBA objects, accessible on the network. All
databases support the same CORBA IDL, and SQL queries can be presented to this interface. The underlying database,
whether Oracle, Sysbase, or even a PC Microsoft Access database, is unknown to the user. Providing CORBA access to
databases is critical to the development of software to support a small manufacturing cell or the extended enterprise. New
databases can be added to the enterprise by implementing the common IDL interface. Because CORBA-based
applications expose standard interfaces to the network, the application becomes available as a component to other
CORBA-based applications, and other CORBA clients, on the Internet and corporate Intranet. This functionality allows
software developers to build up collections of reusable, large-grained services that can be used and customized by other
developers to assemble new applications or integrate existing applications.

2.3 Support for a variety of software clients

While CORBA allows two CORBA objects on two different machines, operating under two different operating
systems, and written in two different programming languages to access each others attributes and methods seamlessly
across a network, it also allows many different client applications to be integrated into the environment. We have adopted
this software engineering development technique: as much as possible, we attempt to separate the GUI from the compute
engine, so to speak. This philosophy allows for more software reuse, especially given how rapidly new GUI
development tools/languages and browser extensions evolve. One example of this speed is the development time between
new web browser versions or the growth of the Java programming language in just one year.
Figure 1 shows how CORBA objects can easily be accessed by a variety of client programs on a variety of hardware
platforms. In the left-hand column of the figure, CORBA objects are located. In the right-hand column, a number of
client technologies are presented. Any client on the right can access any CORBA object, by using an adapter. An
adapter is the technology (either vendor-provided or developed elsewhere) that allows a CORBA object to be accessed
by a desktop client or a client written in some GUI development language. The figure illustrates this plug-and-play client
technology, by matching adapter jacks and client jacks.

Object

Object

Tk/Tcl
adapter

X Display

http
adapter

WWW
Browser

Java
adapter

Applet

OLE
adapter

MS Excel
Visual Basic

Figure 1. Integrating a variety of software clients into our software architecture.

We have developed GUIs and client applications for cell monitoring and cell management using the Tcl/Tk [7]
programming language. The Tcl/Tk applications were developed using an extension [1] of Tcl/Tk, TclDii, which allows
the use of distributed CORBA objects from within Tcl. One of the great strengths of Tcl/Tk is the ease with which XWindows based user interfaces can be assembled, and this CORBA-based extension to Tcl is a very useful tool for rapidprototyping GUIs and for debugging CORBA components. The resulting client GUI is portable across several platforms.

2.4 Integrating to World Wide Web

It goes without saying that the growth of the Internet and its importance to doing business is staggering. More and
more manufacturing companies have an Internet presence and this is central to their way of doing business with
customers, suppliers, and business partners. In addition to the Internet, Intranets (i.e., internal restricted-access
networks, possibly connected by a firewall to the Internet) are becoming commonplace in todays corporations and
laboratories. Web browsers, for example, Netscape Navigator or Microsoft Internet Explorer, can be used to navigate
Intranets and execute internal applications, which can be quite sophisticated.
There are several ways in which a CORBA-based distributed system is accessible on an Intranet or the Internet. One
powerful way is with the inclusion of Java client applets that communicate with CORBA objects, executing on other
computers in the enterprise. Java [2] is an object-oriented platform-independent programming language that has libraries
for Internet access. Many web browsers, specifically Netscape and Internet Explorer, allow Java applets to execute in
your web browser when a web page is downloaded. Since the web browser loads and executes applets on the fly, new
applications and modifications to applications can be deployed instantly. Many ORB vendors have solutions for the

integration of Java clients; we have used OrbixWeb from IONA Technologies. Some ORB vendors also allow the
implementation of CORBA servers in Java. The OMG has not yet specified a mapping from IDL to Java, however, so
only Java clients supporting IIOP will be transportable across ORBs. Note that not all Java-CORBA integration strategies
will work through a corporate firewall since some may require an open socket connection from the applet to the ORB
daemon. Netscapes LiveConnect allows JavaScript programs to access Java applets and HTML forms, thus enabling
HTML form data to be used as input to a Java applets client program to a CORBA object.
Another method of allowing web access to CORBA objects is by using CGI (Common Gateway Interface) scripts
which are clients to the CORBA objects. This may be helpful when a firewall is an issue. We have successfully used
TclDii as a language for writing CGI scripts. Any executable code, for example, written and compiled in C or C++, can
be used in the CGI. Hence, C, C++, and Java are other options for developing and deploying CGI clients to CORBA
objects. These other papers [10] [11] discuss the integration of the World Wide Web and distributed objects (i.e.
CORBA), and the consensus is that this is a very complimentary and powerful technology integration.
In future releases of Netscape client and server software, Netscape ONE [6], the open network environment, has
announced support for IIOP. Thus any Netscape application will be able to communicate transparently with any CORBA
enterprise application.

2.5 Integrating to PC applications software

Orbix allows access to OLE [3] objects by providing an OLE adapter provided by IONA Technologies. This adapter
allows CORBA objects and OLE objects to interact, thus enabling access to and from many PC and Mac desktop
applications. We have used this technology to input numerical data from a Microsoft Excel spreadsheet into a CORBA
design code on the network; the resulting output comes into Excel, and the output can be graphed in Excel. We have
used the same adapter to build Visual Basic applications that execute on a PC and communicate with CORBA objects
across a network. Visual Basic is a good language for rapidly building GUIs and clients for a PC and for interfacing to
OLE objects..

3. MANUFACTURING CELL SOFTWARE

We present the manufacturing cell software from a bottom-up perspective. In Section 3.1, we discuss our standard
software OMG IDL interfaces to the various manufacturing devices in the SAMT. A goal of this effort is illustrated in
Figure 2. At the bottom of the figure are the various machine tools. On the computer associated with each machine tool,
we implement software which provides the OMG IDL interface: by manipulating the software interface, a client program
can control the corresponding machine. With this, then, we can write client software, the cell management software
components, which controls the manufacturing activities in the SAMT. One such client is presented in Section 3.2.
Throughout the discussion, we show how information flows from the enterprise into the manufacturing cell and also from
the cell back into the enterprise. An earlier paper [13] contains gives a more detailed historic account of our
manufacturing software, that does not include the electronic traveler.

Cell Management
Software Components

Software
Interface

...

Machine Tool

Software
Interface
Machine Tool

Figure 2. Cell management software.

3.1 Manufacturing devices

Each of the physical manufacturing objects in the agile manufacturing cell is controlled by a corresponding CORBA
software object. In spite of the apparent differences among the various devices (lathe, robot, storage table, etc.), these
objects all support the same software interface, an IDL interface called IDevice. As seen in Figure 3, the "plug-in" jack
at the top represents the IDevice interface itself. This is the network-visible interface that each manufacturing device
in the cell is required to implement.
Below this is a largely device-independent layer that is common to all of our IDevice implementations. While
dealing with issues like presenting the CORBA interface, threads, access-control, version strings, etc., the functionality of
this layer does not vary greatly for different manufacturing devices. However, the IDevice object is ultimately required
to access the hardware level of a device, for example, to open a chuck or execute a block of NC code. The mechanisms
for accomplishing this do vary greatly and the functionality required of this machine-dependent layer is captured in our
standardized CDevice C++ class. We refer the reader to [13] for a more detailed discussion of CDevice, as it is
beyond the scope of this paper.
IDevice Interface

Network client

Device independent
CDevice class

Device dependent

Lathe

Figure 3. Implementation layers of IDevice.

The IDL used throughout this paper is abbreviated. We refer the interested reader to [15] for the complete IDL.

3.1.1 IDevice interface

The IDL for the IDevice interface is as follows:
interface IDevice : IBaseDev, IAllocDev, IRunDev, IMovePart
{
// Locate program database for device.
IProgDB
GetProgDB();
// Locate operator console for device.
IConsole
GetConsole();
};
IDevice inherits operations and attributes from the following other interfaces:

IBaseDev

Naming and operational status for the machine.

IAllocDev

Controlling access to the machine.

IRunDev

Running processing activities on the machine ( i.e., machining a part).

IMovePart

Transferring material into and out of a machine.

The GetProgDB() operation within IDevice returns a value of type IProgDB , which is an object reference to
its database of manufacturing numerical control (NC) programs. This type corresponds to another IDL interface, thus,
the returned object reference can be used to access the database of NC programs available for the device. As discussed in
Section 2.1, IProgDB assumes nothing about the underlying database. Similarly, the GetConsole() function returns
a reference to an IConsole object. This object can be used to access the operators console for the device, enabling
communication with a human operator.

3.1.2 IBaseDev interface

The IBaseDev interface contains basic attributes that give the "Class" of the device (i.e., lathe, mill, etc.), a unique
ID for the machine (i.e., "Fanuc001), and a readonly string attribute Status. This indicates whether the device is in an
error state, running, or idle, etc. Thus the state of the machine can be monitored by polling the Status attribute of the
device. This readonly attribute is not necessarily constant: the value of the status attribute certainly changes over time, it
is just not directly modifiable by client programs. The IBaseDev interface also allows a client to subscribe to changing
status variables by providing a notification interface. Details are provided in [13].
interface IBaseDev
{
readonly attribute string DeviceClass;
readonly attribute string DeviceID;
readonly attribute string Status;
};

3.1.3 IRunDev interface

The IRunDev interface, another base interface of IDevice, provides operations for controlling the processing
activities on a device. In addition to a pause, resume, and abort functionality, several IDL operations are available to
execute numerical control (NC) programs on a device.
interface
{
boolean
boolean
boolean

IRunDev
Pause ();
Resume ();
Abort ();

... Other operations ...

string

RunThisProgram(in string jobName, in string pgm);

boolean StartThisProgram (in string jobName, in string pgm, in INotify

hnotify);
};

The RunThisProgram()operation provides a way to execute a program on a device. When the requested
processing activity is completed, RunThisProgram() returns a string as its value. Not a status value as one might
expect, the return value instead is the information output of the activity. If the downloaded program performs a
machining operation, then the output of the operation is the physical part machined, and the return value is a null string.
However, the downloaded program may be one that causes a lathe to position a touch probe and measure a part to test
conformance to required tolerances while the part is still in the machine [5]. In this case, the principal output of the step
is the measurement data, and the returned string value holds the probe data. This, then, is our mechanism for ensuring
the easy extraction of process information out of manufacturing devices and into the broader information processing
environment: the act of requesting an operation producing such data yields that data as the return value of the request.
This data will then be entered into the electronic traveler (See Section 4.0) for the particular part. A call to
RunThisProgram() returns only when the operation is complete, causing the caller to block during processing. An
asynchronous call StartThisProgram() immediately returns a boolean success/fail value, indicating whether the
operation was successfully initiated. The string output value that would have been returned by RunThisProgram() is
instead posted to the passed INotify object when the operation is completed. Details can be found in [13].

3.1.4 IMovePart interface

The IMovePart interface provides for material movement between devices. An excerpt of this interface follows:
interface IMovePart
{
// Partner in the material exchange.
boolean SetPartner(in IMovePart dev);
// Exchange the part.
boolean TakeFromPartner();
boolean GiveToPartner();
... Other operations and attributes ...

};

Material movement is accomplished with the operations TakeFromPartner() and GiveToPartner(). Using
these operations, direct device-to-device communications affect exchanging a part without micro-management of cell
manager. A robot device, for example, has an object reference to its partner in the exchange (set in a previous call to the
robots SetPartner() operation), the robot object can manipulate the lathe directly. Thus a call to the
GiveToPartner() operation on the robot results in its assuming responsibility for the transfer, invoking operations on
the lathe interface as needed, and awaiting its replies. This kind of peer-to-peer interaction is very natural and easy to
implement with distributed objects, and is a real strength of the CORBA technology.

3.1.5 Automated and manual operations

In many cases, the operation of machines in the manufacturing cell is not completely automated. This may be
because of limitations in the machine controller, or just because we still rely on the expertise of human machinists in
various manufacturing processes. As we mentioned earlier, the removal humans from the manufacturing process is not a
design goal of our system.
The architecture in place for the SAMT cell control supports both automated and manual activities. Consider, for
example, the operation RunNamedProgram()in interface IRunDev. This operation accepts as an input string the
name of the NC program to run in the manufacturing device, and it is the obligation of the IDevice object
implementation to do whatever is necessary to carry out the requested machining operation. In the fully automated case,
the software can carry out the task by itself. It looks up the provided name in the program database (using the IProgDB
interface) associated with the machine, downloads the resulting NC code into the machine, and runs the code on the
machine.

In the case that the machine does not support automated operation, it still must be a part of the information flow in
the cell. Thus, we still provide an IDevice object for the machine which implements, for example, the
RunNamedProgram() operation. The implementation of this operation is obliged to do whatever is necessary to carry
out the task. In this case, the implementation uses an IConsole interface to perform the operation. The IConsole
interface provides operations needed to carry on a dialog with a human operator. The IConsole interface gives the
machine operator access to the electronic traveler, described in Section 4. The IDevice implementation uses these
operations to request that the operator run the named NC program on the machine, for example.
As seen in Figure 4, from the cell management software perspective, both automated and manual operations appear
the same. This design decision allows us to implement a wider range of manufacturing devices without changing any cell
management software.

Cell Sequencer
RunNamedProgram()

IConsole

IDevice

Cell Sequencer
RunNamedProgram()

IProgDB

IDevice

Figure 4. Automated and manual operations.

3.2 Cell management software

The cell sequencer dynamically attaches to devices, hence, no need to re-compile when a new machine tool comes
on-line or a machine tool disappears. The sequencer accepts jobs, dispatches tasks in the cell, prevents deadlock
situations and guards against starvation of any single job. An abbreviated IDL for the sequencer, ICellSeq, is as
follows:
interface ICellSeq
{
readonly attribute string CellName;
long
AddJob (inout ITraveler, in INotify WhenDone);
void
Pause (in long JobID);
void
Resume (in long JobID);
void
Abort (in long JobID);
boolean DeleteJob (in long JobID);
boolean
boolean
boolean
IDevice
};

AddDevice (in string DevName, in IDevice Dev);

AddRobotDevice (in string DevName, in IDevice Dev);
RemoveDevice (in string DevName);
QueryDevice (in string DevName);

The attribute CellName contains the name of the manufacturing cell, allowing for several cell sequencers to be
coordinated by a shop floor scheduler. A new job can be added to the sequencer with the AddJob() operation. This
operation takes a ITraveler object reference as an argument. When it comes into the cell, the ITraveler object

will contain all of the necessary information to execute the job, including a script of high-level instructions to be
accomplished in the cell. The AddJob operation also takes an INotify object reference so that the sequencers client
can be notified of job completion or error conditions encountered. The return value of the AddJob() operation is of
type long, indicating the assigned JobID given by the sequencer; this JobID can then be used to Pause(), Abort(),
Resume(), or Delete() a job in the sequencer, even while the task dispatcher is operating. Though the cell sequencer
coordinates cell activities, many operations will be accomplished intelligently by the devices. For example, we have
mentioned that all material transfer is performed as peer-to-peer object interaction, independent of the supervisory control
of the task sequencer.
There are four operations in ICellSeq which allow a client to manipulate devices known to the sequencer:
AddDevice(), AddRobotDevice(), RemoveDevice(), and QueryDevice(). Notice that there are two
different operations to add a device to the sequencer: the AddRobotDevice() is necessary to distinguish robot and
transport vehicles from all other manufacturing and storage devices known by the sequencer. The sequencer must know
if a device is a transport device in order to prevent certain deadlock conditions in the cell. By including operations for
dynamically adding and removing devices in a cell sequencer, the sequencer will never have to be recompiled or restarted
when a new IDevice object is available on the network. In theory, this architecture supports a cell sequencer remotely
dispatching jobs to any IDevice objects.
The current task sequencer is quite simple, with no scheduling optimization criteria. This task dispatcher will be
used by a smart scheduling object (ICellSched). This elaborate scheduler will call ICellSeq to dispatch jobs once it
has optimized on "time", "cost", and "priority" values on jobs. The strength of our CORBA implementation is that the
current interface and implementation of ICellSeq should remain as described above once we add this new component
to the cell management activities.

4. ELECTRONIC TRAVELER
As illustrated in Figure 5, an electronic traveler is a key CORBA component in connecting our manufacturing
environment to the larger enterprise. This allows information from design and planning to flow into the manufacturing
facility, and allows manufacturing data to feedback into the broader enterprise. Traditionally, a traveler is the set of
paper documents (drawings, routing information, signatures) which accompany the part as it is manufactured. An
electronic traveler is a persistent object which contains all relevant part data and information generated during design,
process planning, fabrication, and inspection.

Tolerances and Requirements

Process
Planning
NC Program: GTS-2

Design

TRANSFER
RUN

Data Base
Machinist Comments

RUN

Staubli Fanuc CMM

CMM MeasurePart

TRANSFER

Measurement Report.
xxxx
xxxx

Staubli InTable Fanuc

Fanuc MachinePart

TRANSFER

Staubli CMM OutTable

Cell
Manager
Shop
Floor
Figure 5. Electronic Traveler.

RunNamedProgram()
Pause();
Setup();

In short, the traveler object is a persistent CORBA object which contains other object references to part information
accessible in a networked environment, such that designers, process engineers, managers, and machinists can access the
information that they need. There are several advantages to the electronic traveler. First, more complex data (for
example, multimedia data such as video and voice) can be included in the traveler. Second, the traveler can be connected
to PDM systems such that it is archived for future reference. Finally, the traveler can be accessible to many people on a
network, unlike a paper traveler.
The traveler itself is comprised of several CORBA objects; for example, objects which contain contact information on
an engineer, objects which hold manufacturing setup data, objects which describe manufacturing operations, or objects
which contain manufacturing results. The data is stored in databases and PDM systems across the enterprise, yet
logically it appears that the data is stored together. Figure 6 shows a traveler object which contains an object reference to
inspection results that are stored in a database which is geographically distributed from the manufacturing site. CORBA
provides a good infrastructure for building such complex, persistent objects.

4.1 Integration to designers

The traveler is first filled in with information regarding the design of a part or assembly, for example, a CAD file,
requirements information, design engineer contact information, and deliverable information (quantity, inspection
requirements). The object reference to the traveler is then passed to the process planning environment.

4.2 Integration with planning

During process planning, machine tools are selected, the manufacturing setup information (e.g., tooling and
fixturing) is determined, and the manufacturing NC programs are written (either automatically or manually). Planning
for inspection (probe paths determined, critical inspection features identified, etc.) and assembly (weld schedules, subassembly planning, etc.) can be done concurrently. The process scripts, NC codes, and other planning information is all
entered into the traveler and this collection of objects is then sent to the shop.

4.3 Human interfaces to work instructions

In a manufacturing facility, not all machine tools will be automated or operated without a human machinist. In
Section 3.1.5, we showed how our CORBA-based manufacturing devices support humans in the loop. The traveler
provides the information repository from which manufacturing console interfaces can display information. Data entered
into the console interface is then stored in the electronic traveler, providing a record of the manufacturing, inspection,
and assembly steps involved in the fabrication. An operator records normal processing data (date, machine used, lot
number, etc.) and abnormal conditions (machine chatter, for example). The traveler is then archived in a PDM system
and can be referenced during new part design or when maintenance is required on this part.

4.4 Interfacing to databases and PDM systems

The traveler object design supports interfacing to several databases and PDM systems across the enterprise. Figure 6
shows a traveler object where the traveler object is being used at Sandia-Livermore, yet the object implementation for the
inspection results executes on a networked machine in Albuquerque such that the results are stored in a database at
Sandia-Albuquerque. Because CORBA is scaleable to the enterprise level, it is easy to support interfacing to databases
and applications on an Intranet or on the Internet.

Traveler
...
InspectResults

IDevice
IDevice

InspectResults

...

.
Data Base
Data Base

Figure 6. CORBA Objects Logically Unify Data.

4.5 Use of VRML in the traveler

VRML is being used as a way to display a 3D model of the part in the traveler. This visualization capability,
independent of a particular CAD tool, will be useful to designers, process planning engineers, and the machinists on the
shop floor. VRML provides a CAD-neutral format for visualizing, and users can view the model without any CAD
software. This is particularly useful since VRML viewers are available for most every hardware platform, an d many
plug-ins to Netscape allow for easy integration in an Intranet or on the Internet. Figure 7 shows the usefulness of
converting 3D CAD models, for example Pro/ENGINEER files, into VRML.

Designers

Manufacturing floor

Outside Suppliers
Figure 7. Use of VRML in a Manufacturing Environment.
In the traveler, were also using Portable Data Format (PDF), viewable on any platform with Adobe Acrobat
software, to view drawings on-line. Both the drawing conversion and the VRML conversion can be done dynamically by
checking out the current drawing from the PDM, converting the file, and displaying it to a user. Translating on-the-fly
guarantees that the most recent version of the drawing is always seen and that all Pro/ENGINEER files do not need to be

translated and stored as VRML. As discussed in Section 2, CORBA facilitates the seamless access to the PDM,
translation from Pro/ENGINEER to VRML, and web browser viewing.

4.6 Prototype Web-Based Electronic Traveler

We have built a prototype electronic traveler which supports data entry and file attachment from a web browser.
Figure 8 shows how CGI scripts are clients to the CORBA traveler objects which encapsulate databases and a PDM (in
this case WorkGroup Technologies CMS) and make them accessible on the network. Note that automated manufacturing
devices can use the plug-in CORBA jack on the network to write to or read from the traveler.

Web
Client
CGI

CMS API
CMS

Data Base
Data Base

Figure 8. Prototype Electronic Traveler.

Some features of our prototype traveler are these: access control which limits data entry for an individual process to
authorized personnel; recorded fabrication and inspection data for each individual unique serial-numbered part; a record
of each serial-numbered sub-assembly and/or assembly and which serial-numbered piece parts are contained in it; part
status for all travelers in the system; PDF drawings and VRML models of all piece parts, sub-assemblies, and assemblies;
the ability to attach a deviation report, recording any discrepancies or rework orders, to any traveler; and th e ability to
attach any document (e.g. inspection results, Word document, Excel spreadsheet, or image) to the electronic traveler. The
electronic traveler and all associated files are automatically stored in the PDM (WorkGroup Technologies CMS) for
archiving.

5. CONCLUSIONS AND FUTURE WORK

We have presented a CORBA-based manufacturing environment. The distributed object CORBA framework for
management of a manufacturing cell is robust, allowing for easy addition, deletion, and updating of manufacturing
devices in a plug-and-play way. Further, this architecture supports not only manufacturing automation, but human
integration by providing console interfaces to manufacturing devices. CORBA enhances the system integration because it
is an industry-standard for interoperable, distributed objects across heterogeneous hardware and software platforms. The
resulting architecture is scaleable and extensible across a wide-area enterprise.
To support our goal of information-driven manufacturing, we have presented an electronic traveler, a collection of
CORBA persistent objects. A traveler is the collection of routing forms, part drawings, production scripts and other
fabrication information that travels with the part as it is being fabricated. This electronic traveler replaces the paper
travelers of the past and allows on-line access by both designers and manufacturers, possibly at remote sites.

CORBA supports integration with many different information technologies: world wide web, OLE, Java, and
different programming languages. In time, as commercial software vendors provide CORBA interfaces to various
software components, it will be easy to integrate them with our developed manufacturing software.
We are continuing to wrap COTS software, databases, and legacy codes, such that they are accessible in our
manufacturing environment. As such, we are working on a framework to integrate engineering and manufacturing
environments. This framework contains common interfaces to applications and data, support for data translators, and
common services. The framework allows many developers to integrate their applications into the same CORBA-based
enterprise.
One of the necessary missing components in our manufacturing environment is security. CORBA does not, at this
time, have built-in security; however, there are efforts underway in the OMG to provide this service. Currently, our
manufacturing devices, electronic traveler, and cell management software are only accessible on our Intranet; in order to
extend this through the corporate firewall, security is an important concern. Finally, we are going to integrate the
electronic traveler with digital signatures, providing an authenticated electronic signature of any work instruction.

6. ACKNOWLEDGMENTS
The authors express gratitude to a number of people at Sandia National Laboratories. Norm Breazeal, now retired,
was a great visionary and supporter for this work. Jim Costa is a program manager for this work. Hisup Park is the
project lead of the SAMT project. Paul Klevgard contributed significantly to the IDevice interface. Robert Hillaire, Jon
Baldwin, and Tony DeSousa are responsible for various implementations of CDevice. Jill Schwegel, Tracy Walker, Paul
Klevgard, Scot Marburger, and Kristen Witthoeft contributed to the implementation of a prototype electronic traveler. Jill
Schwegel, Barry Hess, and Jim Smith have implemented some of the CORBA translators which we use to translate CAD
files on-the-fly prior to displaying them in a browser.

7. REFERENCES
1. G. Almasi, Suvaiala, A., et. al., TclDii: A TCL Interface to the Orbix Dynamic Invocation Interface, Concurrent
Engineering Research Center, West Virginia University, Morgantown, West Virginia, 1994.
2. K. Arnold and Gosling, J., The Java Programming Language, Addison-Wesley Publishing Company, Reading,
Massachusetts, 1996.
3. K. Brockschmidt, Inside OLE 2, Second Edition, Microsoft Press, Redmond, Washington, 1995.
4. The Common Object Request Broker: Architecture and Specification, OMG Technical Document PTC/96-03-04,
Object Management Group, Framingham, Massachusetts, July 1995.
5. A. J. Hazelton, On-Machine Acceptance of Machined Components, Proceedings of the 10th Annual Meeting of
the American Society of Precision Engineering , Austin, Texas, October 1995.
6. Netscape Communication Corporation, The Netscape ONE Development Environment Vision and Product
Roadmap, white paper, Netscape Communications Corporation, Mountain View, California, July 1996.
7. Ousterhout, J. K., Tcl and the Tk Toolkit, Addison-Wesley Publishing Company, Reading, Massachusetts, 1994.
8. R. Nagel, and Dove, R., editors, 21st Century Manufacturing Enterprise Strategy, An Industry-Led View, Iacocca
Institute, Lehigh University, Bethlehem, Pennsylvania, 1991.
9. H. Park, Sandia Agile Manufacturing Testbed, white paper, Sandia National Laboratories, Livermore,
California, January 1996.
10. O. Rees, Edward, N., et. al., A Web of Distributed Objects, ANSA, Cambridge, United Kingdom, November
1995.
11. M. K. Senehi, Barkmeyer, E., et. al., Manufacturing Systems Integration Initial Architecture Document,
NISTIR 91-4682, National Institute of Standards and Technology, Gaithersburg, Maryland, September 1991.
12. A. Vogel, WWW and Java Threat or Challenge to CORBA?, CRC for Distributed Systems Technology,
University of Queensland (Brisbane), Australia, 1996.

13. R. A. Whiteside, Pancerella, C. M., and Klevgard, P. A., A CORBA-Based Manufacturing Environment, to
appear in the Proceedings of the Hawaii International Conference on Systems Sciences , January 1997.
14. M. J. Wozny, and Regli, W. C., guest editors, Computer Science in Manufacturing, Communications of the
ACM, Vol. 39, No. 2, February 1996.
15. http://primetime.ca.sandia.gov/~raw/cell/index.html.