1. Introduction

The main task of controlling- and automation systems is to guarantee that a given technical process executes as specified and desired. Furthermore the human operator has to be informed about the actual process state, in particular on any relevant changes of the process status. The architecture of the past is characterized by centralized systems for controlling. Typically, all the functional components in such systems are integrated into only one central process control system. Actual data of the process is provided by sensors (i.e. temperature, pressure) as usual, but is sent to the centralized system directly. This central unit in turn calculates and actualizes values for some control-devices of the process (i.e. control valves,..). The application as a whole was serviced by one computer system.

In contrast to the situation described above modern automation systems are characterized by a distributed data processing structure [Baco92]. The entire functionality of the controlling application is divided into parallel working units because of the following reasons:

A basic requirement for the effective use of a distributed control system is to find a suitable partitioning of the application. Then a connection medium must be installed between the distributed components. This medium together with appropriate mechanisms supports the communication requirements between the various and different devices. The sets of activities involved in process control fall into one of the following classes:

Although there is no hierarchy involved in the distributed control systems, we may distinguish between components positioned near the process and such nodes, which are positioned rather close to the human operators and/or supervisors. Consequently we distinguish between "servers" and "clients" and characterize their specific tasks as follows:

Because a server must not exceed a defined guaranteed response time in its actions, servers have to support real-time capabilities. Servers are usually micro-controller applications with special preferences for controlling, driven by a real-time kernel as the operating system, with little or no user interface. The term "hard real time system" is used to indicate that the timing requirements are absolute. "Soft real time" means that failing to meet a deadline will not lead to a catastrophe. Depending on the size and complexity of the control-application, one or more servers are positioned near the process and connected directly to sensors and actuators. Examples of real time systems are control systems for power stations, chemical plants, robot controllers, etc.

Clients and servers are connected by a communication network to represent the whole controlling system. Due to different types of control-servers in such a distributed control-application a heterogeneous structure is quite common in practice. Therefore in general a modern control and automation system is regarded as a client-server system.

The object-oriented application framework for distributed control-applications presented here supports the implementation of a graphical user interface for the client stations. It allows the usage of different data communication protocols and is thus also suitable for a heterogeneous control environment.

In [PoBl93] the concept of an application framework is defined as an extended collection of classes, which cooperate to support a complete application architecture or application model, providing more complete application development support than a simple set of classes.

For our purposes we define an application framework as an integrated object-oriented software system that offers all the application level classes needed by the generic application. The application framework embodies a particular philosophy for structuring the application. It is carrying the control flow for automation applications and offers the frame for a executable application, which has to be specialized for particular use.

The process of building a client application for data visualization consists of inheriting and extending classes from the application framework.

Various servers for special process control functionality from different vendors can be connected to clients with the corresponding communication lines. The client’s task is to communicate with different links and possibly via different protocols. To achieve this the framework contains classes for low-level communication of hardware-interfaces (i.e. serial line, field bus). Some higher protocol-layer classes perform the transformation of the particular data to internal standardized message types, and realize full protocol-transparency. Special message handling classes do the distribution of messages to and from the graphical visualization objects on the screen.