Industrial Networks Connecting Controllers via OPC

Introduction This chapter will provide a rough overview of the problem treated by this Master’s Thesis. All technical devices and expressions will be explained more precisely in the next chapter. Please note that since this is a public thesis, it does not contain sensitive company-internal data. 

1.1 ABB Power Systems ABB Power Systems is one of the world’s leading providers of infrastructure for controlling combined cycle power stations and waste-to-energy plants. Such a plant control infrastructure includes several hardware parts consisting of controllers, input/output-boards and communication devices as well as many software components to engineer, run, observe and analyze the power plant. A power plant control system has to satisfy a broad variety of different needs, from the efficient and reliable control of the turbines and associated supporting functions (such as lube oil) to easy configuration and operation as well as to sophisticated analysis functions addressing technical and economical aspects. 

1.2 Problem Statement Due to high investment costs, the technical management of power plants is a slowgoing business with long life-cycles. Thus, a considerable amount of hardware devices currently in use are tens of years old. For future applications within ABB Power Systems it will be necessary to connect a controller of the newest series used within ABB, Control IT AC800M, with an older controller of the type Advant Controller 160 (AC160). The problem is that these two controllers do not share a fast communication interface of similar type and therefore cannot communicate directly. The standard communication intended for AC160 is Advant Fieldbus 100 (AF100). However, AC800M can support a whole range of buses except for AF100. As a consequence, the communication must be implemented using some relaying technique.

1.2.1 The Use of OPC It was decided in advance to realize the relaying connection using OPC. This solution was chosen because OPC is an open standard and very common in process and automation industry. Furthermore, this solution offers a high potential to be used for similar problems, since a lot of devices support this specification. However, OPC is normally not used for fast controller-to-controller communication but for slower visualization and logging purposes and there is no performance data available for this kind of connection. The use of OPC is therefore both challenging as well as interesting to gain more insights and know-how. It is also to mention that a hardware solution addressing our problem is not available yet. It is therefore necessary to have an alternative way using already available parts, also for testing purposes. 

1.3 Goals The goals of this Master’s Thesis are stated as follows: • Setup and evaluation of a test environment • Setup of test systems • Theoretical and practical evaluation of the test systems concerning performance, availability and reliability. • Identification of improvements and different approaches • Comparison with alternatives As a starting point for the performance requirements, the current implementation was taken. The corresponding quantity and type of variables are displayed in Table 1.1 with 32-bit floating point values (floats) as analog in- and outputs and 1-bit boolean values as so-called status and command bits. In the current configuration with AC450 and AC160, all variables are written to the AF100 fieldbus with a cycle time of 256 milliseconds. Therefore we determined the minimum requirement for round-trip times from one controller to the other to exactly this time. In agreement with the advisors, instead of elaborating the optional extension stated in the task description (Appendix C), we spent more time on trying out a second PROFIBUS approach and the theoretical derivation of a redundancy concept. 

1.4 Structure For the reader’s convenience this Master’s Thesis is structured thematically starting with an overview of components and terms (2) in the next chapter. The following chapters inform about the test system setup (3), the evaluations that were made (4) and finally the results (5). In a subsequent chapter the subject redundancy is treated (6) before the thesis comes to an end with the conclusion and outlook (7). Additional information as well as a CD-ROM containing more detailed data is located in the appendix of this thesis.

Components and Terms In this chapter, hardware and software parts as well as terms used for our test system and evaluations will be described. Some additional devices and programs concerning redundancy are introduced not until the chapter according. Information on the version numbers can be found in Appendix B. Figure 2.1: Schematic test system overview 

2.1 Basic Terms • Performance, in this thesis, refers to the capability of a communication component in means of speed and throughput. 

• Availability is the term for the probability that a system will perform its specified functions when used under stated conditions. A common mathematical definition of operational availability is Ao = MT BF/(MT BF + MDT), whereas MTBF is the “mean time between failure” and MDT the “mean down time” [2]. However, in this thesis, availability is used in a more general manner, since the basis for mathematical operations is not available.

6.2 Components and Terms • Reliability means the probability of a device remaining failure free during a specified time interval, e.g. the maintenance interval: R = e λt

• Redundancy is the implementation of extra components in addition to the ones needed for normal operation. Thus, redundancy normally increases reliability and availability. 

2.2 OPC OPC, originally short for “OLE for Process Control”, is an open, standardized software communication interface specification launched in 1996 by a task force of different automation companies, later forming the OPC Foundation. As the former name indicates, OPC is an adaption of Microsoft’s Object Linking and Embedding OLE1 to the process control business, which used to be highly proprietary at that point of time. Thus it was almost impossible to efficiently combine products of different vendors. By providing so-called OPC servers with their devices, buses and software, vendors open their products to any OPC compliant client able to connect to the server for data exchange. Usually, an OPC server can handle several clients at once, while these clients—e.g. visualization or calculation applications—can connect to different servers in order to obtain their needed information. Figure 2.2: Classical OPC configuration Over the years, the OPC Foundation has been adding eight additional speci- fications to the original one, therefore the name OPC was freed from its original meaning and is now used as an umbrella term [3]. Some important specifications are quickly explained in the following: 

• DA (Data Access) is the original and most widely used standard of OPC. Its purpose is the cyclic polling of real time data, for example for visualization purposes.

• HDA (Historical Data Access), in contrary, specifies the access to already stored data. 

• AE (Alarms and Events) describes the non-cyclic, event-based exchange of alarms and events. 

• Data eXchange is a specification from 2002 which regulates the direct communication between two OPC servers. For this Master’s Thesis it was made use both of the DA specification for the main purpose of communication as well as the AE specification in order to display and log round-trip times. Unfortunately, the promising Data eXchange specification is almost inexistent in practice and could therefore not be used in our thesis. The underlying technique to exchange data is the component object model COM of Microsoft Windows, therefore OPC can only run on Windows operating systems [4]. A new generation of OPC specifications recently published is called OPC Unified Architecture (OPC UA) and is independent of COM, thus being able to run on more operating systems as well as embedded devices [5]. 

2.2.1 OPC Data Access OPC DA is organized in the hierarchical structure server, group and item. Items correspond to variables and can be read and written. Furthermore, a quality and time stamp is provided with each of them. When reading items, the value usually comes from the OPC server’s cache, which is updated periodically with the values of the device (or bus, component). However, it is usually possible to force a read directly from the device. Clients organize their items in groups, which for example share the same access method and update rate. Each OPC server has an unique name, some vendors even offer the operation of multiple servers for the same device. OPC DA provides different methods to access items, first of all synchronous and asynchronous read and write operations. More important to us, there is also a subscription mechanism, which is commonly used by modern clients in order to reduce communication. That is, the client group subscribes to the server which then “pushes” values towards the client only if they changed respectively exceed a pre-defined dead-band. The client can force an update of all these values by issuing a refresh call, which corresponds to an asynchronous read for all items of a group [6]. 

2.3 Programmable Logic Controllers This section informs about the two controllers involved and about the controller that has to be replaced. Please notice that we use the term controller equivalent to programmable logic controller (PLC) throughout our Master’s Thesis.