A CORBA-Based Remote Monitoring System for Factory …



A CORBA-Based Remote Monitoring System for Factory Automation

Kazuhiro Kusunoki(1)(3), Isao Imai(1), Haruyuki Ohtani(1),

Tetsuo Nakakawaji(1), Michitaka Ohshima(2), and Kazuo Ushijima(3)

(1) Information Technology R&D Center, Mitsubishi Electric Corporation, Japan.

(2) Nagoya Works, Mitsubishi Electric Corporation, Japan.

(3) Graduate School of Information Science and Electrical Engineering,

Kyushu University, Japan.

Abstract

Supporting rapid response to changing customer requirements, reduction in both time and cost of manufacturing process, and integration within a heterogeneous wide-area networked enterprise are necessary to increase worldwide competitiveness in manufacturing. We propose a CORBA-based architecture to realize that manufacturing environment. We have developed an ORB for PLC to realize that architecture. And we have developed two prototypes of remote monitoring system for factory automation, which are a manufacturing line monitoring system and a remote PLC monitoring with using Web browser, to examine feasibility and effectiveness of our proposed architecture. According to experiments of these prototypes, we show the feasibility and effectiveness of our proposed CORBA-based architecture.

1. Introduction

To increase worldwide competitiveness in manufacturing, it is necessary for manufacturing environment to support rapid response to changing customer requirements, reduction in both time and cost of the manufacturing process, and integration within a heterogeneous 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 to integrate manufacturing management functions and manufacturing functions.

An information architecture to realize such integration must be scalable and interoperable. Internet technology is also key technology.

A distributed object technology[4] is one of solutions to integrate various functions. Each function can be regarded as an object.

It is possible to integrate heterogeneous hardware and software platforms in manufacturing environment by using a distributed object technology.

There are some examples of distributed object technology 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 applied it to a remote monitoring system to examine the feasibility and effectiveness of a CORBA-based architecture.

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

The system architecture based on CORBA is shown in Figure 1. The following are features of this architecture.

u To integrate heterogeneous PLCs, we defined object model of PLC.

u An ORB provides the basic object interaction capabilities through network.

u An application on FA controller can call method which is provided by server object. An FA controller corresponds to cell level in CIM (Computer Integrated Manufacturing) model defined in ISO TC184.

u Internet technology is applicable without additional mechanism in PLC side.

[pic]

Figure 1. A CORBA-based remote monitoring system for FA (prototype)

The following are abstracts of components. In Figure 1, colored modules were developed by ourselves.

1) Manufacturing Line monitoring application : This module provides following functions.

u searching a configuration of hardware units of PLC,

u searching information about each hardware units,

u searching dynamic information such as total operation time,

u searching and changing information about I/O relay address,

u searching and changing status of each memories, and

u searching and changing status of I/O devices.

8) OLE server : This OLE server is a gateway between OLE environment and CORBA environment to provide OLE interface to an application.

9) Remote monitoring application : This is an application to monitor manufacturing line from remote site through Internet. This application has the same functions as manufacturing line monitoring application described in (1).

10) PLC objects : These CORBA-based objects represent components or functions of a PLC.

11) ORB for PLC : This is an ORB implemented to PLC. Features are compactness of module size and high performance of response time.

12) Ladder Program : This controls I/O device simulator.

The definition 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 to be specified to control the I/O device or to set a monitoring condition. Therefore, not only sequence control programs but also manufacturing line monitoring programs have to be changed when I/O memory address is changed because of changing configuration 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.

Object-oriented technology can solve the above problems. Following design policies were adopted in the design of PLC objects.

1) Modeled objects should be used both to monitor the production status of manufacturing line and 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 autonomy 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.

The defined object model of PLC is shown in Figure 2. The following are details of classes.

[pic]

Figure 2. Object Model of PLC

PLC class manages all objects related to PLC and provides functions for starting and stopping PLC.

Hardware class is a base class of hardware units of PLC. This class has attributes of maintenance information such as establishment time and operating start time, and abstract name.

CPU unit class, power unit class, communication unit class, input/output unit class, and another unit class have attributes of hardware specification information such as a manufacturer name and type name, and maintenance information such as total operating time and version number of system ROM.

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 memory type and data type (bit data or byte data).

Register memory class, timer memory class, counter memory class, data memory class, shared memory class, input memory class, and output memory class correspond to each memories in a PLC. A PLC works continually by scanning a program which is usually programmed by ladder program. I/O devices are controlled through input/output memory which reflects the status of I/O devices.

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 middleware for PLC.

1) For each process, the most suitable PLCs have to be selected to produce high quality products with high efficiency 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 interoperability with other vendor's distributed object management middleware. (Openness)

2) In general, CPU and memory performance of controllers 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 remote monitoring application must have short response time compared with remote access application used in office 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 Internet environment as well as LAN environment. (Expansiveness)

To satisfy design policy (1), we adopted CORBA(Common Object Request Broker Architecture) standardized in OMG(Object Management Group) and developed ORB (Object Request Broker) based on CORBA.

It is not necessary to implement all functions in the CORBA specification. Only functions required for FA environment should be implemented. In FA environment, the number of such objects as controllers, I/O devices, and applications is fixed when a system starts. And a client application already knows which method of an object is to be invoked. Therefore, dynamic creation/deletion of objects and dynamic method invocation have not been implemented in the ORB for FA environment. By this, design policy (2) was achieved.

[pic]

Figure.3 Software Architecture of our ORB for PLC

Figure 3 shows the software architecture of our ORB for PLC.

PLC related objects are created based on the definition of object model of PLC described in Section 2.2.

ORB core processes communication protocol between a client application and server objects.

Object Adapter creates a unique identifier for each object within network, and dispatches a corresponding method called by a client application to an appropriate object.

Method parameter processing for PLC related objects execute marshaling and un-marshaling parameters of a called method. In a general-purpose ORB, these codes are created by IDL(Interface Definition Language) compiler automatically. IDL compiler refers object interface definitions in IDL files. However we implemented these codes manually in every method. The reasons are,

1) The program created by IDL compiler is generally large.

2) The number of defined methods for PLC object model is not so large.

3) It is possible to optimize modules by sharing common 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-ORB Protocol) specified in CORBA2.0 to satisfy design policy (4).

2.4 IOR (Interoperable Object Reference)

In a CORBA environment in which IIOP is used, the IOR is the identifier of the object.

[pic]

Figure 4. Data structure of IOR

Figure 4 shows the data structure of IOR. In Figure 4, colored parts of IOR show the types of data. An object adapter in an ORB receives "object_key" in IOR , method name and parameters to be executed. The object key in IOR is the key to search an object to execute called method. The CORBA specification does not define 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 efficiently.

In our prototype system, we adopted following definition of object key.

The type of object key is octet string and the length is indefinite. Object key based on character string causes overhead searching of object because of comparing character strings. We adopted 32 bits integer key. Upper 16-bits is class identifier for each class defined 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 manufacturing line monitoring system to which a CORBA-based architecture is applied. We discuss feasibility and effectiveness 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 concept of this method is analogous to that of existing manufacturing line monitoring application.

[pic]

Figure 5. Example of Objects

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, manufacturing 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 of I/O device.

Calling sequences and processings in I/O device object are as follows.

1) A manufacturing line monitoring application must get an IOR of an I/O device object that represents the switch. A get_IOdeviceRef() operation, which is provided by PLC object, is used. There are two types of methods to specify target 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 device 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.

For a status check function of type 2, manufacturing line monitoring application uses read_DataMem ( ) operation. This operation is provided by input memory class. Input parameters of read_DataMem ( ) operation are memory type ("X") and address number ("0"). Output parameter is the status of "X0".

In input memory object, following processes are executed.

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 object. The reason is,

u If both input memory object and I/O device object 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, must be modified if I/O device is re-connected to another address of input memory.

Because of providing a status check function of this type 1, a manufacturing line monitoring application turns out to be independent of physical memory address of I/O devices. That is, a manufacturing line application turns to be more flexible to a configuration 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 flexibility to a manufacturing line monitoring application. However, it is easy to change existing manufacturing line monitoring applications to object-oriented program by using a status check function of type 2.

3.2 Event notification function by I/O device monitoring

Event notification function is one of the most significant functions. The following are necessary functions for event notification.

u A manufacturing line monitoring application can set conditions for issuing event notification.

u A PLC checks the specified conditions by the manufacturing line monitoring applications specified.

u A PLC sends event notification to the manufacturing line monitoring application if specified conditions are met.

In existing systems, manufacturing line monitoring applications send polling message to each PLC to check the status of event conditions, or some parts of distributed shared memory are allocated for event notification flags. However, a manufacturing line monitoring 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 written in control programs. It restricts extensibility of control programs.

In this prototype system, necessary event conditions 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 technology can be applied under our architecture.

We also developed a remote PLC monitoring system 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.

Figure 6 shows action scenarios.

[pic]

Figure 6. Action Scenario of remote PLC monitoring system

1) In Web browser, a type code of target PLC is specified.

2) A Java applet corresponding to the target PLC is downloaded from maintenance center server.

3) The downloaded Java applet runs on Web browser by communicating with server objects.

4) The remote PLC monitoring application user can check the status of the PLC by using the downloaded 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, the same functions can be provided. Our prototype system has two features compared with that.

u In WWW server based system, status of all memories in PLC must be translated to HTML data. It causes time delay to real data. Toward this, our prototype directly accesses to I/O device through object. A remote monitoring application can get real data.

u Because PLC objects provide basic functions to control PLC, a remote monitoring application can be customized to select suitable functions from them. Toward this, WWW server based system has restricted extensibility because customization must be executed in WWW server side.

Internet technology is applicable without any additional mechanism in PLC side. By this, our proposed architecture is effective to use the Internet technology.

5. Conclusion

In this paper, we proposed a CORBA-based architecture to realize world-wide competitive manufacturing environment. We presented our ORB for PLC to realize that architecture. And then, we presented prototype remote monitoring system for factory automation to examine feasibility and effectiveness of our proposed architecture.

The authors plan to examine memory performance and response time performance, and implement ORB in PLC to examine feasibility and effectiveness of proposed architecture in real systems.

References

1] Computer Science in manufacturing, the Communications of the ACM, Vol.39, No.2 (1996)

2] Computer Integrated Manufacturing (CIM) Application Framework Specification 1.3, SEMATECH Technology Transfer #93061697F-ENG (1996)

3] Whiteside, R.A., Pancerella, C.M. and Klevgard, P.A.: A CORBA-Based Manufacturing Environment, Proc. of the Hawaii International Conference on System Sciences, (1997).

4] Orfali, R., Harkey, D., and Edwards, J., The Essential Distributed Objects Survival Guide, John Wiley and Sons, Inc., New York, New York (1996)

5] Object Management Group : The Common Object Request Broker: Architecture and Specification, 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 Services(LNS) Architecture Technical Overview ,

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download