A CORBA-Based Remote Monitoring System
for Factory Automation
Kazuhiro Kusunokiy, Isao Imaiy , Haruyuki Ohtaniy
Tetsuo Nakakawajiy , Michitaka Ohshimaz
y Information Technology R&D Center
z Nagoya Works
Mitsubishi Electric Corporation
fkusunoki,imai,ohtani,nakawajig@ipt.isl.melco.co.jp
ohshima@kai.mei.melco.co.jp
Abstract
Supporting rapid response to changing customer re-
quirements, reduction in both time and cost of man-
ufacturing process, and integration within a hetero-
geneous wide-area networked enterprise are necessary
to increase worldwide competitiveness in manufactur-
ing. We propose a CORBA-based architecture to re-
alize that manufacturing environment. We have de-
veloped an ORB for PLC to realize that architecture.
And we have developed two prototypes of remote mon-
itoring system for factory automation, which are a
manufacturing line monitoring system and a remote
PLC monitoring with using Web browser, to examine
feasibility and eectiveness of our proposed architec-
ture. According to experiments of these prototypes, we
show the feasibility and eectiveness of our proposed
CORBA-based architecture.
1 Introduction
To increase worldwide competitiveness in manufac-
Kazuo Ushijima
Graduate School of Information
Science and Electrical Engineering
Kyushu University
ushijima@csce.kyushu-u.ac.jp
by using a distributed object technology.
There are some examples of distributed object tech-
nology such as CORBA(Common Object Request
Broker Architecture) [5] and DCOM(Distributed
Common Object Model)[6]. We have selected CORBA
because it is independent of operating system.
A distributed object management middleware for
manufacturing devices is needed to apply a distributed
object technology to manufacturing environment.
We have developed an ORB(object request broker)
for PLC (Programmable Logic Controller). We ap-
plied it to a remote monitoring system to examine the
feasibility and eectiveness of a CORBA-based archi-
tecture.
In the next section we discuss system architecture.
In sections 3 and 4, we discuss feasibility to apply our
ORB to remote monitoring systems.
2 The System Architecture
2.1 Overview
turing, it is necessary for manufacturing environment
exible for
to support rapid response to changing customer re-
quirements, reduction in both time and cost of the
manufacturing process, and integration within a het-
erogeneous wide-area networked enterprise, that is, an
agile manufacturing[1][2][3].
Product design sections and manufacturing sections
may be geographically distributed and networked. To
realize an agile manufacturing, it is very important to
integrate product design functions and manufacturing
functions. For the same reason, it is very important
Because a CORBA specication is very
implementation, it is possible to implement an ORB
which is suitable for FA systems. From that reason, we
have selected CORBA as distributed object technol-
ogy for manufacturing environment. In detail, we have
not provided an IDL compiler for developing server
objects from the standpoint of memory performance.
The system architecture based on CORBA is shown
in Figure 1. The following are features of this archi-
tecture.
to integrate manufacturing management functions and
manufacturing functions.
An information architecture to realize such integra-
tion must be scalable and interoperable. Internet tech-
nology is also key technology.
A distributed object technology[4] is one of solu-
tions to integrate various functions. Each function
can be regarded as an object.
 To integrate heterogeneous PLCs, we dened ob-
ject model of PLC.
 An ORB provides the basic object interaction ca-
pabilities through network.
 An application on FA controller can call method
which is provided by server object. An FA con-
troller corresponds to cell level in CIM (Computer
It is possible to integrate heterogeneous hardware Integrated Manufacturing) model dened in ISO
and software platforms in manufacturing environment TC184.
 Manufacturing Line
Monitoring Application Netscape
Remote Remote
monitoring Remote Monitoring
OLE Server Application monitoring
FA Controller Terminal Terminal (Mobile)
VB4.0
Orbix for JAVA
Windows applet

Windows95 Windows95

10Base-T HUB
PLC Objects

MELSECNET/10
MELSEC (10Mbps)
ORB for PLC Access
Driver Prototype ORB Ladder I/O Device Simulator
for PLC Program
WindowsNT

Figure 1: A CORBA-based remote monitoring system based on proposed architecture

 Internet technology is applicable without addi- (3) Remote monitoring application : This is an
tional mechanism in PLC side. application to monitor manufacturing line from
remote site through Internet. This application
In our proposed architecture of a CORBA-based has the same functions as manufacturing line
remote monitoring system for FA, hard real-time con- monitoring application described in (1).
trol of I/O devices is executed by PLCs. PLC objects,
which are abstraction models of PLCs to information (4) PLC objects : These CORBA-based objects
systems, are used as a gateway to real-time control represent components or functions of a PLC.
sub-system.
The following are abstracts of software components. (5) ORB for PLC : This is an ORB aimed to be
In Figure 1, colored software modules were developed implemented in a PLC. Features are compactness
by ourselves. of module size and high performance of response
time.
(1) Manufacturing Line monitoring application : (6) Ladder Program : This controls I/O device
This module provides following functions. simulator.
 searching a conguration of hardware units
of PLC,
 searching information about each hardware
units,
 searching dynamic information such as total
operation time,
 searching and changing information about
The denition of the object model of PLC and the
development of ORB for PLC are most critical in the
development of this prototype system. In 2.2 and 2.3,
we describe the details of them.
2.2 Object modeling of PLC
In existing manufacturing systems, I/O memory
address, to which each I/O device is connected, has
I/O relay address, to be specied to control the I/O device or to set a
monitoring condition. Therefore, not only sequence
 searching and changing status of each mem- control programs but also manufacturing line monitor-
ories, and ing programs have to be changed when I/O memory
 searching and changing status of I/O de-
vices.
(2) OLE server : This OLE server is a gateway be-
tween OLE environment and CORBA environ-
ment to provide OLE interface to an application.
address is changed because of changing conguration
of manufacturing lines.
It is expected to become very easy to maintain a
manufacturing line monitoring application if it uses
an abstract name to check the status of PLC and I/O
device instead of a physical memory address.
 PLC Hardware
maintenance information
maintenance information abstract name
get information
get information get abstract name
execution PLC change abstract name
stop PLC

CPU unit Power unit Communication Unit Input/Output unit Another unit
maintenace inf. maintenance inf. maintenance inf. maintenance inf. maintenance inf.
spec. inf. spec. inf. spec. inf. spec. inf. spec. inf.

get information get information get information get information get information

Memory
memory type
data type
read value
write value

Register Memory Timer Memory Counter Memory Output Memory Input Memory I/O device
values values device type
values values values
abstract name
read value read value
address to I/O memory
write value write value
read value read value read value
get status
write value write value write value
change status
get abstract name
change abstract name
Data Memory Shared Memory
values values
read value read value
write value write value

Figure 2: Object Model of PLC

Object-oriented technology can solve the above information such as establishment time and oper-
problems. Following design policies were adopted in ating start time, and abstract name.
the design of PLC objects.
(3) CPU unit class, power unit class, commu-
(1) Modeled objects should be used both to monitor nication unit class, input/output unit class,
the production status of manufacturing line and and another unit class have attributes of hard-
to maintain manufacturing devices.
(2) PLC controls all I/O devices in existing systems.
However, some intelligent I/O devices which can
connect to network directly and act with au-
tonomy such like LONWORKS[7] are appearing.
Therefore, we separated functions of I/O devices
and those of PLC. Our modeled object would be
possible to be used when autonomous I/O devices
are used in manufacturing system.
ware specication information such as a manu-
facturer name and type name, and maintenance
information such as total operating time and ver-
sion number of system ROM.
(4) Memory class is a base class of each type of
memories in PLC. A PLC has a various types of
computing resources called memories to control
I/O devices. Memory class has attributes of mem-
ory type and data type (bit data or byte data).
The dened object model of PLC is shown in Figure (5) Register memory class, timer memory
2. The following are details of classes. class, counter memory class, data memory
class, shared memory class, input memory
(1) PLC class manages all objects related to PLC class, and output memory class correspond
and provides functions for starting and stopping to each memories in a PLC. A PLC works con-
PLC. tinually by scanning a program which is usually
programmed by ladder program. I/O devices are
(2) Hardware class is a base class of hardware units controlled through input/output memory which
of PLC. This class has attributes of maintenance re
ects the status of I/O devices.
(6) I/O device class is a virtual I/O device for an
application to check the status of I/O device with
using an abstract name of each I/O device.
2.3 Software architecture of distributed
object management for PLC
The following design policies were adopted when we
implemented distributed object management middle-
ware for PLC.
(1) For each process, the most suitable PLCs have
of an object is to be invoked. Therefore, dynamic cre-
ation/deletion of objects and dynamic method invo-
cation have not been implemented in the ORB for FA
environment. By this, design policy (2) was achieved.
Figure 3 shows the software architecture of our
ORB for PLC.
PLC related objects are created based on the def-
inition of object model of PLC described in Section
2.2.
ORB core processes communication protocol be-
tween a client application and server objects.
to be selected to produce high quality products
with high eciency and safety. In that case, the
same types of PLCs or the same vendor's PLCs
are not always used. Therefore our distributed
object management middleware must have inter-
operability with other vendor's distributed object
management middleware. (Openness)
Object Adapter creates a unique identier for
each object within network, and dispatches a corre-
sponding method called by a client application to an
appropriate object.
Method parameter processing for PLC re-
lated objects execute marshaling and un-marshaling
parameters of a called method. In a general-purpose
ORB, these codes are created by IDL(Interface Deni-
(2) In general, CPU and memory performance of con- tion Language) compiler automatically. IDL compiler
trollers are restricted. And most controllers do
not have second storage devices such as hard disk.
Therefore, execution module size of distributed
object management middleware should be small.
(Compactness)
(3) A manufacturing line monitoring application and
refers object interface denitions in IDL les. How-
ever we implemented these codes manually in every
method. The reasons are,
(1) The program created by IDL compiler is generally
large.
remote monitoring application must have short
response time compared with remote access ap-
plication used in oce automation. Processing
algorithm in our distributed object management
middleware should have high performance. (High
Performance)
(4) The open communication protocol between client
and server objects must be adopted in the In-
ternet environment as well as LAN environment.
(2) The number of dened methods for PLC object
model is not so large.
(3) It is possible to optimize modules by sharing com-
mon processing parts.
PLC related objects execute called method.
We implemented the ORB and PLC related objects
within one process to improve processing performance.
Furthermore, we adopted IIOP (Internet Inter-
(Expansiveness) ORB Protocol) specied in CORBA2.0 to satisfy de-
sign policy (4).
To satisfy design policy (1), 2.4 Interoperable Object Reference
we adopted CORBA(Common Object Request Bro- In a CORBA environment in which IIOP is used,
ker Architecture) standardized in OMG(Object Man- the IOR(Interoperable Object Reference) is the iden-
agement Group) and developed ORB (Object Request tier of the object.
Broker) based on CORBA.

type_id profiles
string sequence <Tagged Profile>
PLC related objects
tag profile_data
Method parameter processing ProfileId sequence <octet>
for PLC related objects
ProfileId iiop_version host port object_key
unsigned long Version string unsigned short sequence <octet>
Object Adapter
major minor
ORB Core char char

Figure 3: Software Architecture of our ORB for PLC Figure 4: Data Structure of IOR

It is not necessary to implement all functions in the Figure 4 shows the data structure of IOR. In Fig-
CORBA specication. Only functions required for FA ure 4, colored parts of IOR show the types of data.
environment should be implemented. In FA environ- An object adapter in an ORB receives "object key" in
ment, the number of such objects as controllers, I/O IOR , method name and parameters to be executed.
devices, and applications is xed when a system starts. The object key in IOR is the key to search an object
And a client application already knows which method to execute called method. The CORBA specication
 PLC object

Management
Management Management
Management
Table
Table Table
Table

CPU Unit Data Memory

object object
Power Unit Shared Memory
object object
Comm. Unit Register Memory
object object
Input Unit Timer Memory
(Connected to “X0”) object object
Output Unit Counter Memory
object object

Input Memory object Output Memory object

Management Table Management
Management
Address 0 ... 1023 Table
Table
Object Ref. ...

I/O device object

attributes
Name = Switch1
Address = “X0”

Figure 5: Example of Objects

does not dene any algorithm to create object key.
A PLC for a large scale system controls more than
two thousands of I/O devices. This means that more
than two thousands of I/O device objects are created.
Therefore it is necessary for object adapter to search
the object to execute called method eciently.
In our prototype system, we adopted following def-
inition of object key.
The type of object key is octet string and the length
concept of this method is analogous to that of existing
manufacturing line monitoring application.
Figure 5 shows an example of objects showing one
switch is connected to a PLC. The switch is connected
to input memory "X0".
For a status check function of type 1, manufactur-
ing line monitoring application uses read IODevVal ()
operation which is provided by I/O device class. This
operation has only one output parameter of the status
is indenite. Object key based on character string of I/O device.
causes overhead searching of object because of com- Calling sequences and processings in I/O device ob-
paring character strings. We adopted 32 bits integer ject are as follows.
key. Upper 16-bits is class identier for each class de-
ned in 2.2. Lower 16-bits is sequential number of
objects whose number is changed depending on each
FA system.
3 A Manufacturing Line Monitoring
In this section, we present a prototype manufactur-
ing line monitoring system to which a CORBA-based
architecture is applied. We discuss feasibility and ef-
fectiveness of out architecture.
3.1 Status check functions of I/O devices
Two types of status check functions of I/O device
are provided. One is to recognize I/O device as object
and to access I/O device through that object (Type 1).
The other is to specify input/output memory address
to which target I/O device is connected (Type 2). The
(1) A manufacturing line monitoring application
must get an IOR of an I/O device object that
represents the switch. A get IOdeviceRef() oper-
ation, which is provided by PLC object, is used.
There are two types of methods to specify tar-
get I/O device object. One is to set the name
of "switch1" in input parameter. The other is to
set memory type "X" and address "0" in input
parameters.
(2) The manufacturing line monitoring application
calls read DataMem () operation to the I/O de-
vice object. This operation has only one output
parameter of the status of I/O device.
(3) In I/O device object, the status of "switch1" is
checked and returned to the manufacturing line
 monitoring application. In existing systems, manufacturing line monitor-
ing applications send polling message to each PLC to
For a status check function of type 2, manufactur- check the status of event conditions, or some parts
ing line monitoring application uses read DataMem ( of distributed shared memory are allocated for event
) operation. This operation is provided by input mem-
ags. However, a manufacturing line mon-
ory class. Input parameters of read DataMem ( ) op-
eration are memory type ("X") and address number
("0"). Output parameter is the status of "X0".
In input memory object, following processes are ex-
ecuted.
(1) Searching the management table to detect target
I/O device object by using address number.
(2) Calling read IODevVal () operation to target I/O
device object.
It is possible to check the status of "X0" directly in
input memory object. However we designed to check
the status only through operation to I/O device ob-
ject. The reason is,
 If both input memory object and I/O device ob-
ject have the status of I/O device, consistency has
to be maintained. It causes processing delay.
Manufacturing line monitoring application, in
which status check functions of this type are used,
notication
itoring application can not detect events immediately
in case of polling. In the case that distributed shared
memory is used to detect event, data must be copied
to the shared memory. This procedure must be writ-
ten in control programs. It restricts extensibility of
control programs.
In this prototype system, necessary event condi-
tions are maintained in the server object, which checks
the event condition.
4 Application to the Remote PLC
Monitoring with using Web Browser
Internet technology is also important for an agile
manufacturing. It is important that the Internet tech-
nology can be applied under our architecture.
We also developed a remote PLC monitoring sys-
tem with using Web browser for prototype system.
This prototype system can be applied to the intranet
based manufacturing management system and remote
fault diagnostic system of PLC.
must be modied if I/O device is re-connected to an- Figure 6 shows action scenarios.
other address of input memory. (1) In Web browser, a type code of target PLC is
Because of providing a status check function of this
type 1, a manufacturing line monitoring application
turns out to be independent of physical memory ad-
dress of I/O devices. That is, a manufacturing line
application turns to be more
specied.
(2) A Java applet corresponding to the target PLC is
downloaded from maintenance center server.
exible to a congura-
tion changing of manufacturing line.
A status check function of type 2 is provided to
inherit programming style adopted while developing
legacy software in the past. It gives no
exibility to check the status of the PLC by using the down-
a manufacturing line monitoring application. How-
ever, it is easy to change existing manufacturing line
monitoring applications to object-oriented program by
using a status check function of type 2.
Existing SCADA software, such as FIX/DMACS,
polls a status of I/O device with minimum cyclic time
of 50 ms. We have evaluated that necessary time to
process ORB related modules is less than 4 ms in our
early performance evaluation. This proved to be very
usable to connect the user interface for line monitoring
to real-time I/O control sub-system.
(3) The downloaded Java applet runs on Web browser
by communicating with server objects.
(4) The remote PLC monitoring application user can
loaded Java applet.
The Java applet is a CORBA client and can access
to objects in a PLC. In this prototype system, Web
browser uses OrbixWeb, and communicates with PLC
objects by IIOP.
Because of the security restriction of Java, a host
from which Java applet was downloaded should be the
same host that PLC objects are implemented.
If WWW server was implemented in PLC and all
PLC data in memories were translated to HTML data,
3.2 Event notication function by I/O the same functions can be provided. Our prototype
device monitoring system has two features compared with that.
Event notication function is one of the most signif-  In WWW server based system, status of all mem-
icant functions. The following are necessary functions ories in PLC must be translated to HTML data.
for event notication. It causes time delay to real data. Toward this, our
 A manufacturing line monitoring application can prototype directly accesses to I/O device through
set conditions for issuing event notication. object. A remote monitoring application can get
real data.
 A PLC checks the specied conditions by the
manufacturing line monitoring applications spec-  Because PLC objects provide basic functions to
ied. control PLC, a remote monitoring application can
be customized to select suitable functions from
 A PLC sends event notication to the manufac- them. Toward this, WWW server based system
turing line monitoring application if specied con- has restricted extensibility because customization
ditions are met. must be executed in WWW server side.
 Web Browser

Remote Maintenance
Remote Monitoring Menu Page
Terminal
JAVA
applet

Download
get information Maintenance Program
Objects control PLC Search
target PLC’s
Java applet

Objects Java Applet

Java Applet
Java Applet

Maintenance Center Server

Figure 6: Action scenario of remote PLC monitoring system

 Internet technology is applicable without any ad- References

ditional mechanism in PLC side. By this, our [1] Computer Science in manufacturing, the Commu-
proposed architecture is eective to use the In- nications of the ACM, Vol.39, No.2, 1996.
ternet technology.
[2] Computer Integrated Manufacturing (CIM) Appli-
5 Conclusion
In this paper, we proposed a CORBA-based archi-
tecture to realize world-wide competitive manufactur-
ing environment. We presented our ORB for PLC to
realize that architecture. And then, we presented pro-
totype remote monitoring system for factory automa-
tion to examine feasibility and eectiveness of our pro-
posed architecture.
Compared with existing FA system, our CORBA-
based architecture is estimated as followings.
 A software architecture especially for remote
monitoring system has become more scalable.
 It has become easier to integrate heterogeneous
cation Framework Specication 1.3, SEMATECH
Technology Transfer #93061697F-ENG ,1996.
[3] Whiteside, R.A., Pancerella, C.M. and Klev-
gard, P.A.: A CORBA-Based Manufactur-
ing Environment, Proc. of the Hawaii Inter-
national Conference on System Sciences, 1997.
http://nittany.ca.sandia.gov:8001
/DistObjsMan.html
[4] Orfali, R., Harkey, D., and Edwards, J., The Es-
sential Distributed Objects Survival Guide, John
Wiley and Sons, Inc., New York, New York ,1996.
[5] Object Management Group : The Common Object
FA systems.
 Internet technology can be integrated to remote
monitoring system for factory automation.
 Communication latency to monitor status of I/O
devices may be applicable from the result of early
performance evaluation.
The authors plan to examine memory performance
and response time performance, and implement ORB
in PLC to examine feasibility and eectiveness of pro-
posed architecture in real systems.
Request Broker: Architecture and Specication,
Technical Report, Revision 2.0 ,1995.
[6] Chappell, D., Understanding ActiveX and OLE,
Microsoft Press, Redmond, Washington ,1996.
[7] Blomseth, R., Capolongo, W., Dolin, B. and
Lund, J. : The LONWORKS Network Ser-
vices(LNS) Architecture Technical Overview ,
http://www.echelon.com
/LonWorks Networks/wpapers.htm