We selected process automation software as an example of custom software .... The benefits of using OOP in this area are easier configuration and a gain in ...
published in : Journal of Object-Oreinted Programming, May 1994
Object-Oriented Process Control Software Pirklbauer K., Plösch R., Weinreich R. C. Doppler Laboratory for Software Engineering Johannes Kepler University of Linz Altenbergerstr. 69, A-4040 Linz, Austria
Abstract The cycle from one release of a software product to the next is becoming shorter and shorter. Especially for custom software products (nonstandard software), implementation productivity needs to be increased. The reuse of prefabricated software components and the implementation of reusable and extensible software are of great importance. The objectoriented programming paradigm has already proven to fulfill these demands in the area of graphical user interfaces or visualization in general, but its applicability undoubtedly extends beyond user interfaces. Thus we initiated a project with the aim to examine the impact object-oriented programming can have on the design and implementation of automation software. In this paper we present a framework for process automation software which was implemented on SUN SPARC stations using ET++ (a user interface application framework) and C++. In addition to the design of the framework, we describe the implementation of a process control software for a ladle furnace (part of a steel plant) using our framework.
1
Introduction
The time between two releases of a software product is diminishing. This has been made possible by making easily extensible and maintainable software. In the area of customized software with many slightly different versions, flexible and easily configurable software is of prime importance for a developer to be competitive. Flexible software can be achieved by: •
Reuse. An existing software component should be reused whenever the problem is similar or identical to the problem it was designed to solve. This has some great advantages. Time to construct individual software is minimized by reducing the timeconsuming reimplementation of software components. Basic components used in different software products can be enhanced by making the changes once. And errors in components can be corrected the same way.
•
Reusability. Flexible software should consist of parts that can be reused in succeeding projects. For this reason software products should be made up of small, well-defined components. The more extensive a component is, the less is the probability that it can be used again.
•
Extensibility and flexible software design. In software design, future extensions should be foreseen, or at least the design and implementation should not ruin the chance of extending the software in the future.
The use of object-oriented programming (OOP) in conjunction with class libraries promises to lead to software design meeting the above requirements. Especially the OOP mechanisms like inheritance, polymorphism and dynamic binding enable the development of more flexible, more easily maintainable, and less error-prone software.
2
Demonstrations of the power of this new programming paradigm have already been given in various projects. Most of these projects—from the Smalltalk system [Gold85] until now—have been in the area of highly interactive graphical user interfaces. But there is no reason to suppose that OOP’s facilitating power should be limited to the implementation of user interfaces. Industry, especially where there is a need for custom software, has high expectations that this programming paradigm could also considerably rationalize software development in other application areas. We therefore initiated this project to examine the usefulness of OOP for a typical industrial application. We selected process automation software as an example of custom software used in many industrial areas. The aim was to develop semifinished software components for process automation in a steel plant and to evaluate these components by using them in a specific project.
2
Process Control Software
2.1 General Aspects Process automation software can usually be related to one of the three levels shown in Figure 1. planning level
automation control level
hardware control level
machines Figure 1: The three levels of automation software
The hardware control level covers all processes for controlling machines on a low level. These processes, which are responsible for one or several machines, receive commands from the level above and send special commands to their machines. In most cases these processes are implemented on special hardware which usually is delivered with the controlling software. The automation control level covers all processes for controlling production. This level is usually structured according to the tasks and not according to the machine structure. The automation control level processes communicate with the machines and with the user at the control station. The planning level is the top level of an automation system. It is the connection of all automation control level components working on the same product or using common data. Processes on the planning level control power consumption, make machine capacity calculations, and plan the production. In the following we concentrate on the automation control level and its processes and call this part of automation software process control software.
3
Our analysis of conventionally implemented process control software and numerous discussions with experts involved in the construction of automation systems helped us specify the special requirements in this area. •
Several tasks working in parallel have to be controlled by process control software that is often distributed throughout the entire plant. This requirement leads to a distributed system as the base architecture for process control software.
•
Processes on the automation control level have to exchange data with each other and with hardware and planning level processes. Thus in an object-oriented implementation of process control software, the basic class library has to provide communication services.
•
Automation systems require an error-tolerant implementation. Production should not be stopped if an error occurs. Processes that died because of an error have to be restarted and broken communication lines have to be reconnected. For this reason supervisor processes have to observe the automation processes and to act in case of errors.
•
Additionally visualization of the current state of production and of machine occupation is required at the control panel .
2.2 Special Requirements for Steel Plant Automation Our aim was to implement semifinished software components for steel plant automation projects. Automation software in this field appeared to have some further requirements:
3
•
In steel production, quality is a very important aspect. For each steel part the whole production history has to be stored. For this reason great amounts of data have to be shared between the automation processes. This necessitates a mechanism for data management.
•
In conventionally implemented automation control systems, in case of an error the production must not be stopped. In the steel plant area in most cases it is impossible to stop the production. This requires the possibility of manually troubleshooting by sending manually entered commands from the control panel to the hardware control level processes and by entering missing data in case of communication breakdown or other problems. The intensive user interaction is also necessary because the production sequence and the processing steps cannot be foreseen exactly.
Object-oriented Framework for Process Control Software
Based on these requirements we designed an object-oriented framework consisting of the following parts (shown in Figure 2): Communication library provides easily configurable and flexible communication among processes. Data management library provides mechanisms for the management of a large amount of process data. Process management library provides mechanisms for process management, which includes synchronizing and warm boot of crashed processes. Process control Library provides process control classes for controlling the treatment processing steps.
4
Control panel library provides visualization of process data in conjunction with the design of a modern graphical user interface for a control panel. This object-oriented framework for process control software is named ProcessTalk. ProcessTalk is an application framework as defined in [Schmu86]. It was implemented in C++ using the application framework ET++ [Wein89] on SUN™ workstations. As such, ProcessTalk is an extension of the application framework ET++, which was developed for applications with highly interactive graphical user interfaces.
ProcessTalk Framework
Process Control Library
Control Panel Library
Data Management Libraray
Process Management Library
Communication Library
Figure 2: ProcessTalk structure
In the following sections the components of ProcessTalk are described in more detail. To show how these libraries can be applied in practice, a ladle furnace system is presented as a case study of an industrial automation system.
3.1 Case Study: Ladle Furnace A ladle furnace is a station in the steel production process where the final chemistry and temperature of the steel bath is achieved. The steel is tapped at BOF (Basic Oxygen Furnace)converter or electric ore furnace into a ladle, which is transferred to the ladle furnace (see Figure 3). At the ladle furnace station the steel bath (also called heat) is treated. While controlling temperature, oxygen content and chemical analysis of the heat alloying, desulfurization and deoxidation agents are added. After the steel reaches a specified quality level, the ladle is sent to the continuous caster. The automation software at the ladle furnace station is part of the automation control level. Connections are needed to the hardware control level, the laboratory, the melting station, and the caster. Typically the ladle furnace automation processes, the laboratory processes, and the caster automation processes run on different computers. These processes have to communicate with each other to exchange steel data, processing times, etc. Machines are controlled by sending messages to the hardware control level process and this process forwards information from the machines to the rest of the automation software system; eg., the hardware control level process receives and forwards temperature values and oxygen data from the machines.
5
The ladle furnace software consists of several parts: •
The user interface part interacts with the user at the control panel.
•
Six processes (data managers) manage process and steel bath data.
•
The metallurgical-model and the thermal-model processes are responsible for controlling the heat and calculating cost-optimized agent weights.
•
The central controlling process communicates with the other parts and controls the processing of the steel. Planning Level
Ladle Furnace Data Managers
Laboratory Thermal Model Process
Melting Station
Central Controlling Process
Hardware Level
Metallurgical Model Process
Userinterface
Hardware Level
Caster
Hardware Level
Figure 3: Ladle furnace system
This example will be mentioned throughout the library descriptions to show the applicability of the libraries.
4
Communication Library
4.1 Class Library A distributed system requires flexible communication between its components. On the one hand, fast communication lines are also needed (even if they are not fully reliable) as slow but reliable communication lines. On the other hand, connections on one machine and connections crossing machine boundaries are needed. UNIX™ supports several communication services for interprocess communication. A flexible communication class library should allow the use of all of these services, with the different interfaces of these services hidden from the user. It is also
6
desirable that communication services can be changed without changing the source code of programs using them. As an additional requirement, we defined the possibility to send objects as well as conventional data structures (i.e., integers, strings, records, etc.) to allow an object-oriented design of the whole system. In distributed applications the flow of messages and data is of vital importance to understanding how the system works. A tool to monitor the communication lines provides a comfortable extension of the communication library. Architecture The communication library is the basis for other essential parts of this project, i.e., data management and process management. The underlying communication model is simple and was tailored to the special requirements of process automation. Nevertheless, it can easily be extended to meet further requirements. In the current implementation, each process may maintain one mailbox, which can be addressed by one UNIX interprocess communication (IPC) service [Sun90]. A communication manager, which is implemented as a class, manages the communication relationships among processes. An extension of the communication model, for example, to provide more than one mailbox per process, would require only a minor extension of the communication manager. Mailbox
Internet Socket
Process A
Shared Memory
Process B
Mailbox Internet Socket
Process C
Shared Memory
Mailbox Figure 4: Communication lines between processes
All processes using the communication library can send and receive data. Data can be not only a stream of bytes but also an object (in the sense of OOP). The communication is connectionbased. Connectionless communication (datagrams) is not supported yet. An established connection is unidirectional. As a consequence, two connections (which can use different IPCservices, depending on the mailboxes of the communicating processes) are needed to exchange data between two processes in either direction (see connection between processes B and C in Figure 4). Finally, communication may be synchronous (blocking) or asynchronous (nonblocking). An extension of the provided functionality, for example, to support connectionless communication (datagrams), means adding new classes or extending (by subclassing) the classes for communication services (depicted in Figure 5). The location of processes influences the use of IPC-services. While memory-based services like message queues can only be used for communication between processes located on the same machine, file-based services like TLI also enable communication between processes located on different machines.
7
A special class provides facilities that are especially helpful and necessary for real-time applications, namely time-outs and filters. Filters allow the specification of which messages a process is to receive and handle. Arriving messages that are not specified in the filter raise an exception and can be treated specially. In addition to the ET++ programming environment, which allows the inspection of the objects of an application at execution time, a communication test tool was included in the communication library. This tool not only allows observation of the flow of messages (message name and sender or receiver) but also inspection of arbitrary data that was sent with a message. The standard ET++ object inspector was integrated; it is used for inspecting objects associated with a message by double clicking on the message in the test tool. PTPort
ReadPort
ReadMsg Port
ReadShared MemPort
abstract class for receiving messages
ReadSocket Port
ReadUNIX SocketPort
abstract class for communication services
ReadTLI Port
WritePort
WriteMsg Port
WriteShared MemPort
ReadInternet SocketPort
abstract class for sending messages
WriteSocket Port
WriteUNIX SocketPort
WriteTLI Port
WriteInternet SocketPort
Figure 5: Communication service classes
The communication test tool can be used by linking it to the application without needing to make any changes in source code files or in configuration files. Results The benefits of using OOP in this area are easier configuration and a gain in flexibility and extensibility. To change the communication service with which a particular process can be addressed, only an entry in a configuration file has to be modified. There is no need for recompilation or relinking. Even unforeseen communication services can be added this way, although with relinking. This is achieved by using abstraction (a common superclass for all services) and metainformation about the system (to determine which subclasses of a certain abstract class are available). Almost the same techniques are used to design the other components of ProcessTalk to be as flexible as the communication library. Using the communication class library is also very simple. The classes ReadPort and WritePort define a common protocol for all communication services (see Figure 5). Users of the library need only know their simple class interfaces, regardless which service is being used.
4.2 Case Study: Ladle Furnace In the ladle furnace automation software, communication lines are needed between the central controlling process and the other processes on the automation control level (compare Figure 3). These lines are used to coordinate the processes and to exchange data. To control the machines, a connection to the hardware control level process is also needed. Communication lines are also necessary to connect the ladle furnace system to other parts of the global automation system (caster, melting station, laboratory, planning level). The communication class library is used for all these connections; no modifications or extensions to the given classes were made.
8
5
Data Management Library
5.1 Class Library Distributed control process applications often require mechanisms for the management of a large amount of data shared among processes. Consistency and security of data are important, as is a sufficient level of performance. We defined as an additional requirement the possibility of storing (C++/ET++) objects. Architecture System data is managed using a client/server architecture. We provide the class ObjectServer as an abstract interface to access data servers. A client may store and retrieve C++ objects to/from a server by using subclasses of the class ObjectServer without knowing whether these objects are stored in an object-oriented database, in a plain file, or in memory. For communication between clients and servers, the communication library described above is used. Object Server
Process OServer
interface to object manager process
abstract class
GemStone OServer
interface to oo. database GemStone
Figure 6: Data-server interfaces
The currently implemented interfaces are depicted in Figure 6. The class GemStoneOServer provides an interface to the object-oriented database GemStone [Serv90]. The class ProcessOServer is an interface to object managers that we implemented. Object managers are processes managing objects in memory. They are lightweight and provide a higher degree of performance than an object-oriented database. However, the consistency of data is preserved only by a simple locking mechanism. Results Due to the use of abstraction, the underlying data management facility can be changed without affecting any clients. This results in greater flexibility and easier extensibility of the whole system.
5.2 Case Study: Ladle Furnace The implementation of the ladle furnace system uses many object servers, each managing logically related data. For example, one object server is used for data and history of the current steel bath (heat). Other object servers are for planned and for finished heats. Crew and metallurgical data are also stored using object servers. The use of many servers and hence the distribution of data helps to prevent bottlenecks. Clients using such servers are, for example, the user-interface process and the central controlling process. In the ladle furnace system, the data management class library was used without any modifications.
9
6
Process Management Library
6.1 Class Library Distributed systems consist of a number of cooperating processes that communicate and share some kind of resources (e.g., data). A mechanism has to be provided for the coordination and supervision of processes. Distributed process control systems have to be highly reliable and at least have to provide mechanisms ensuring the integrity of the entire system after breakdowns of parts of the system. Architecture In our implementation, a distributed process control system consists of a number of supervisory processes and other processes connected by communication lines using the communication class library. Every supervisory process (at least one on each computer) controls a number of other processes. It is responsible for starting the controlled processes, for synchronizing them with the rest of the system, and for controlling them during execution. A supervisory process is also responsible for automatically restarting and resynchronizing crashed processes. Figure 7 shows the main classes for process management. Although processes can have different behavior and structure (e.g., processes managing a graphical user interface, data server processes, etc.), common behavior and structure could be factored out in the class NormalProcess. This class provides, for example, basic mechanisms to handle incoming messages. A specialization like the class ObjMgrProcess handles messages for accessing objects in a data store; the class ActionHandlerProcess forwards incoming messages to special message handlers, e.g., automatons, where the code to be executed depends on the incoming message and the internal state of an automaton. Sometimes processes in a distributed application need a highly interactive graphical user interface, which can be constructed by using the ET++ class library. However, to minimize resources and to keep the system flexible, the graphical user interface classes are strictly separated from the process management classes. Process
Normal Process
Supervisor
ActionHandler Process
ObjMgr Process
Figure 7: Classes for process management
These classes can easily be used in any distributed application without major modifications. Due to object-oriented techniques it proved easy to construct new processes by using the frame provided by the classes Process and NormalProcess and their subclasses.
6.2 Case Study: Ladle Furnace In the ladle furnace system the process management library is used, too. Processes on the same machine are controlled by a supervisory process. The distribution of processes on several machines is very flexible. However, it is a good idea to have the data management processes
10
and the processes using the data on the same machine. In this case the faster memory-based communication lines can be used. For each supervisory process, a subclass of the class Supervisor has to be implemented. In these subclasses the child processes and other supervisors for coordination have to be declared. A child process can be any subclass of NormalProcess. In the ladle furnace implementation, the central controlling process (object of class ActionHandlerProcess), the user-interface process (object of class NormalProcess) and the data-manager processes (objects of class ObjManager) are controlled by one supervisory process. To improve flexibility and comfort of process management, these supervisory processes could be generated. In the section 'Further Work', the idea of implementing such a configuration tool is picked up again.
7
Process Control Library
7.1 Class Library The real aim of process automation software is to monitor and control product treatment. The control task has to be restartable, so that a system crash cannot confuse the product treatment or data consistency. The tasks must also be interruptable to facilitate a treatment modification by the crew. Architecture The process control library consists of three parts. The first part is a class Action for processing steps performed during product treatment. Because the concrete treatment is specific for each automation system, subclasses of the class Action must be created. The class Action is an abstract class. It not only provides a uniform interface for all process control classes, but offers some vital functionality for its subclasses. The second part of the process control library supports the design of restartable control software. It provides mechanisms to store execution states in a file and to restore these states after restarting crashed processes. The third part provides a framework for interrupting the execution of process steps. It enables interruptions of actions at any time by the crew or by special system events (e.g. time-outs). Results This part of the automation system is the most specific part for the current application. There are not as many general and reusable classes as in the other parts. Nevertheless, we believe that in this area class libraries for special purposes will reduce implementation work.
7.2 Case Study: Ladle Furnace In the area of steel production, the class library for process control has to provide the functionality for controlling and supervising the treatment of steel at a ladle furnace. In general a process step, from the point of view of the underlying automation software, consists of a sequence of commands like sending messages to other application processes, waiting for specific messages from other processes, reading and/or changing data in data stores, and performing various calculations.
11
Figure 8 shows the class hierarchy for process steps, where each process step for the ladle furnace is represented by a process control class. These classes provide the entire functionality for the control of the ladle furnace. Action
Material Adding
Bulk Alloying
Intermediate Alloying
abstract class for material addition
Fine Alloying
Deoxidation
abstract class
Oxygen Measuring
Desulphurization
Temperature Measuring
Sample Taking
Shape Control
Figure 8: Classes for automation control
The central controlling process of the ladle furnace automation system is derived from the class ActionHandlerProcess. This means that this process performs a sequence of the process steps mentioned above, depending on the quality requirements for the current batch of steel. These Action subclasses are specific for a steel plant and for a ladle furnace in particular. Nevertheless, with some redesign large portions of the process control classes can be reused in other ladle furnace projects. This should also prove true for other technical systems in a steel plant, like continuous casting units.
8
Control Panel Library
8.1 Class Library The control panel serves as the interface between operators and the automation system. To control the product treatment, the processing states and the corresponding data have to be visualized at the control panel. For the interaction between crew and automation system, a modern graphical user interface is required. Architecture Object-oriented programming has been used for user interface implementation for a long time. So there are many class libraries supporting user interface construction. ET++, the library we based ProcessTalk on, also supports this area. Only extensions of the provided classes were necessary to achieve a comfortable toolbox for user interface programming. We designed classes for viewing editable and noneditable numbers, texts and lists on the screen, for input of numbers in different formats with integrated range checking, for image buttons, and for other user interface components. Results Although the user interface implementation is well supported by class libraries, some additional classes can simplify this task substantially.
8.2 Case Study: Ladle Furnace Alongside the process control classes the control panel classes are an important part of the ladle furnace automation system. Several user interface masks guide the interaction between system and user (crew). A primary aim was to design a nearly modeless interface where the user can decide what to see or what to do next. If the user has to attend to a certain matter, dialogs pop
12
up. Like all modern user interfaces, the user can see all possible commands in menus. We designed the control panel for the use with a mouse as well. Even though a mouse on modern computers is nothing unusual in the steel plant automation area the mouse is not generally accepted until now. Nevertheless, we believe that modern user interface design and mouse usage can not be separated and these techniques can not be stopped in the steel area.
9
Quantitative Aspects of the Implementation
Figure 9 gives an overview of the classes and lines of code needed for the ladle furnace project. These figures are compared with the classes and lines of code reused from the ProcessTalk application framework. In addition to the libraries of the ProcessTalk framework, a library for process data was used. This library is specific to ladle furnace applications. Approximately 40% of the code of the classes for process data can be generated automatically on a basis of a high level specification. Components
Classes
Communication library Data management library
Lines Of Code
Project specific
General
Reuse of framework classes
0
24
100%
Project specific
General
Reuse of framework classes
0
3067
100%
8
5
38%
756
829
52%
Process management library
11
17
61%
1300
3106
70%
Process control library
10
9%
1809
Control panel library
13
59%
4543
Process data library
38
0%
2378
Total
80
Average
1? 19 0? 66
10786
695 ? 1705 0?
28% 27% 0%
9402
45%
47%
Figure 9: Classes and lines of code of the ProcessTalk framework
Figure 9 shows that only about 55% of the code of the ladle furnace automation system is project specific and had to be implemented. The rest came from the ProcessTalk application framework. In addition to the number of classes from the ProcessTalk framework, roughly 150 classes of the ET++ class library were reused. A generalized prediction of reuse for the process control classes and the classes for process data can only be given after having used them in other projects. That is why these numbers are marked with a question mark.
1 0 Conclusions The aims of this object-oriented implementation were to increase the reuse of software in the automation software area, to design flexible and reusable software, and to achieve highly extensible products. The reusability of our software components is shown in the section above. Even if final statements regarding reusability cannot be made before using this framework in several projects, the implementation of the ProcessTalk framework is a considerable step forward. We believe that the classes for communication, data management, process management and visualization are highly reusable in any system where communicating processes and shared resources are involved, e.g., office automation. Only the reusability of the process control class library is restricted to automation software for similar apparatus in a (steel) plant.
13
Additionally, the object-oriented paradigm permitted high extensibility and flexibility of the components. The use of metainformation also increased the flexibility. Experience has shown that object-oriented programming is very powerful in cases where general behavior and common structure can be factored out. Although it is more difficult to find general behavior in this area than in graphical user interfaces our implementation showed that there is general behavior and that the concepts of object-oriented programming and application frameworks in particular also proove very valuable in this domain.
1 1 Further Work We mentioned above that several parts of an automation software system, e.g., parts of the process data library and the supervisory processes, could be automatically generated. In particular, an interactive design of the communication structure would increase the flexibility and configurability of the software. Work on such a prototyping-oriented tool for system configuration has already started. Another area for further work that emerged from this project is the detailed run-time debugging and inspection of distributed systems. The inspection tool included in the communication library is a step in this direction, but there are many more problems with debugging processes working parallel on common data and exchanging messages and data.
Acknowledgements This project was partially funded by Austrian Industries. We would like to thank the C. Doppler Gesellschaft, Mr. Scheidl, Mr. Nowak, Mr. Pinger, Mr. Hubmer and Mr. Krendl for their cooperative support during this project.
References [Gold85]
Goldberg A., Robson D.: Smalltalk-80—The Language and its Implementation, Addison Wesley, 1985
[Schmu86] Schmucker K.: Object-Oriented Programming for the Macintosh, Hayden Book Company, Hasbrouck Heights, N.J., 1986 [Serv90]
Servio Corporation: GemStone C++ Interface, Servio Corporation, 1990
[Sun90]
Sun Microsystems Inc.: SunOS Reference Manuals, Sun Microsystems Inc., 1990
[Wein89]
Weinand A., Gamma E., Marty R.: Design and Implementation of ET++, a Seamless Object-Oriented Application Framework, in: Structured Programming, Vol. 10., No. 2, Springer-Verlag, 1989
