Proceedings of The
IEEE International Conference on Industrial Technology, 1996
esign of ~ ~ t ~ b u t e d
Control System Sofhoare Using Client-Sewer Architecture
Yih-Ping Luh, Shean-Shyong Chiou, Jau-Woie Chang
Department of Mechanical Engineering National Taiwan University, Taipei, Taiwan, China Abstract- In the paper, we adopt the clientlserver architecture in
designing a distributed control system software. In industrial automation, each applicati a combination of
many server and client pro a data acquisition system is several data collecting processes (the clients) plus several
common server processes such as the IO server, processes. These distributed processes cooperate their own functionality to achieve the system-wide tasks. In the clientkener architecture, we reduce the software complexity and increase the software reusability of a large control system.
I. INTRODUCTION
The design philosophy of a traditional control software
has been set to include functionality in one package. This philo when the system is
relatively small. How mplexity of a system increase, the complexi oftware will increase exponentially fast [ 11. Therefore, a client-server architecture must be used to reduce the software complexity. It is also
reported that the clientkener technology can make it easier
for users to access information, to use and to develop applications, and to manage a distributed computing environment [2].
In addition to control system software, we introduce the concept of the control system architecture. Different architecture has different system characteristics [3]. A
complete system and software architecture are given in this paper.
The rest of the paper is organized as follows: Section I1
briefly states some design issues of a control system. Section I11 introduces our implementation environment. Finally, some concluding remarks are discussed in section IV.
11. CONTROL SYSTEM
0-7803-3 104-4
I
348A complete control system has to include some functiom
such as data IO, monitoring, alarming, computing, data acquisition, etc. A large system is developed using highly modular and expandable software architec
control functions are implemented independen other. In the paper, we put some related fun
within one control node. Each control node should achieve its preset functionality. However, there is another issue about joining these control nodes together to accomplish system level tasks.
"Control architecture makes a control system from control components [3]." The control architecture determines the stability, structure and ways of communication among control nodes. More details about control architecture have been described in several papers where the reader is referred [3-51 and the references therein. In the paper, we pick the heterarchical form as the con architecture. The main advantages of heterarchical con architecture are reducing software complexity, reducing coupling among modules, and implicit fault-tolerance.
As the size of a control system increase, the complexity of the control software increases exponentially fast. Therefore, find a way to reduce the complexity becomes important. "Modularity" is the answer to the problem [l]. In this paper, we propose a client/server technology in designing control software. The cliendsever technology has the feature of modularity and other benefits such as: lower cost, higher productivity, longer system life cycle, and better software reusability. The clienthemer architecture is an approach to
software where the client asks for and receives services from
the server. These client and server applications are executed independently from each other.
111. IMPLEMENTATION
Network 2 I I I * UNIX UPJlX TCPAP TCPAP TCPAP % Network 1
Our system topology is described in Fig. 1. The network 1 is the shop floor control level and the network 2 is the MIS (Management Information System) level. Each node in the network 1 uses the QNX as its operating system and dual network path for communication purpose. The QNX operating system is a distributed real time operating system
[6,7]. The FLEET (Fault-Tolerant, Load-balancing, Efficient, Extensible, Transparent) networking technology in QNX makes the application more reliable and efficient. When there is more than one path used for communication, the
QNX transmits data over both network paths simultaneously.
Also, if any one path is failure, it will reroute all data through another path.
In the MIS level, we build our network application in the TCPAP network environment with socket library. The socket library is available on a lot of platforms, such as UNIX BSD socket, Windows socket, etc. With the socket library, we can
Fig. 2 IO node software configuration
Anv node in Neiwork 1 or
X
Network 2 IO node in Network 1IOSERV
U
10 node in Network 1 Any node in Network 1 or Network 2Fig. 3 Relationship between client applications and IOSERV processes
easily transfer our application to another operating system.
.
In the paper, we adopt the UNIX as our operatirig system in network 2.B. Software Architecture
We design our control software in a cliendsever approach. As described in Fig. 2, there are one IOSERV process and many low level physical IO processes in each 10 node located in network 1. The IOSERV process maintains a real time IO point data table and takes the responsibility of client requests. Any client IO request is sent to the IQSERV process within each IO node. The real time IO point data table is updated by low level physical IO processes. In the software environment, we can develop our client application independently from IOSERV process. As depicted in Fig. 3,
the client application can only access these IO points through IOSERV processes, and all cliendserver processes are independent from each other. Compared to the traditional method which application may access IO points directly, this method not only isolates the application from hardware interface, but also simplified the application program. As a result, any time we need to modify the cliendserver application process, it is not RUXSSZQ to modify other processes because of cliendserver independence.
As shown in Fig. 4, there are two IQSERV processes, relative to A/D processes and PLC driver process
respectively. In addition, the alarm system must have one
client application associated with alarming, also the monitoring system must have one client application associate
V. REFERENCES Network 2 4 I I w I I
5;
Monitoring v,Fig. 4 An application example
with data monitoring. Both systems need to access IO point data though two common IOSERV processes. Whenever we need to update either of these two systems, it does not need to change another system at all. The monitoring system is built on the UNIX operating system using TCPlIP socket programming. The $arming system is built on the K/QNX environment through the Inter-Process Communication.
IV. CONCLUSION
This paper has outlined some considerations in the software design of distributed control system. The client/server software architecture not only reduces the complexity of control software design, but also makes
applications independent from each other. This independence makes the software maintenance easier. We also give an application example in the paper. With the growing needs of the control system software, further research about the cliendserver application is certainly necessary.
[l] Maarten Boasson, "Control System Software," IEEE Trans. on Automatic Control, Vol. 38, No. 7, Jul. 1993, pp.1094-1106. \
[2] JrJung Lyu, "On Developing
an
Inventory Management System in the CIienVServer Environment," Comimters and Industrial Engineering, Vol. 29, No. 1-4, 1995, pp.93-97.[3]
ha.
Dilts, N.P. Boyd, H.H. Whorms, "The Evolution of Control Aritechtures for Automated Manufacturing Systems," Journal of Manufacturing Systems, Vol. 10,NO. 1, pp. 79-93.
[4] Thomas J. Crowe, Edward J. Stahlman, "A proposed structure for distributed shopfloor control," Integrated Manufacturing Systems, Vol. 6, No. 6, 1995, pp.31-36.
[5] N.A. .Duffle, R.S. Piper, "Nonhierarchical control of manufacturing systems," Journal of Manufacturing Systems, Vol. 5 , No. 2, 1986, pp. 137-139.
[6] Dan Hildebrand, "An Architectural Overview of QNX,"
Proceeding of the Usenix Workshop
on
Micro-Kernel& Other Kernel Architectures, Seattle, April 1992. [7] QNX System Architecture, Quantum System Ltd., 1992.
