Implementation of a Virtual Plant using SCADA/HMI Technology

Implementation of a Virtual Plant

Using SCADA/HMI Technologies

A Report submitted in partial fulfillment of the

requirement for the degree of

B.Sc. (HON)

In

Electrical and Electronic Engineering

Under Supervision of

Dr. Adulrahman Ali Karrar

By

Mazin Khalid Mohammed Eltayeb

To

Department of Electrical and Electronic Engineering

Faculty of Engineering

University of Khartoum

July 2009

I

Acknowledgment

Here I would like to thank people who have helped and supported me during the work

of this thesis. First of all thanks to my supervisor Dr. Abdulrahman for the guidance

through the thesis and for all the help that he brought me.

I am deeply indebted to my project partner, Husam Aldeen Samir for his hard work,

encouragement, team spirit and the unforgettable times we have spent.

And I would like to thank the most important people in my life, my family.

II

Abstract

In times of increasing costs and highly competitive market, mistakes and uncertainty

in dealing with control systems are not affordable. At the heart of every decision

making is an understanding of the relationship between the decision variables to the

expected outcome.

Process simulators or virtual plants provide a tool for better understanding of the

plant and a platform for designing and testing new control and optimization strategies.

However and because of its high initial cost and extensive development effort, such

plant simulators was a luxury restricted to nuclear and aerospace industries.

The aim of this project was do develop a method to design and implement a virtual

plant environment utilizing existing technologies encountered in the field of

supervisory control and data acquisition (SCADA). The approach was to use a

simulation software package and to utilize existing human machine interface (HMI)

software to emulate the plant control system. Linking of the two programs was

achieved using OPC technology.

The method developed resulted in a system that is efficient, flexible and cost

effective. The ease of this approach enables implementation of virtual plants for much

smaller applications.

III

المستخلص

يف ػصشا زا انزي حخزاذ ف حكانف اإلخاج ؛ صبح حذود اخطاء ظاو انخحكى وػذو قخ ي األيىس انيت

الميك قبىهلا، ونزنك البذ ي انبحذ ػ ظاو حماكاة إفخشاض ري حكهفت يؼقىنت حاسب انصاػاث انصغرية

إ صغ انقشاس ؼخذ بشكم أساس ػهى فهى انؼالقت بني يخغرياح املخخهفت وزا ض احلصىل ػهى . واملخىسطت

انخدت املخىقؼت نهقشاس، وميكا انقىل بؤ ػهت احملاكاة اإلفخشاضت ملشؤة يا متثم األسضت انيت حقىد إيل فهى أفضم

وواقؼ نهشؤة وبانخايل متثم قطت اإلطالق ألي حصى او إخخباس خذذ وحضغ اضا اسخشاحداث انخطىس

. املسخقبه

ظى احملاكاة اإلفشاضت انسائذة حانا ػانت انخكانف سىاء كاج انخكانف األونت أو خهىد حطىش ز األظت ،

.األيش انزي جيؼهها حكاد حكى قصشا ػهى جماالث انصاػاث انىوت وانفضائبت

باسخخذاو انخكىنىخا فخشاض اظاو حماكاة اهلذف ي زا املششوع ى انقاو بىضغ طشقت نخصى وحفز

، مت اسخخذاو بشايح حماكاة (SCADA) اإلششايف واحلصىل ػهى انبااث أظت انخحكىجمال يف املىخىدة

يخؼذد األغشاض ي أخم منزخت و حماكاة املشؤة ، و كزنك اسخخذيج بشجماث انشبط بني االسا و انت

(HMI) بغشض حقهذ واخهاث ظاو انخحكى ، ػهت انشبط بني ز انرباجمني متج باسخخذاو حكىنىخا

.OPCال

األيش انزي ميك ي اسخخذاو ظى احملاكاة اإلفخشاضت . انطشقت املخبؼت خدج ػ ظاو اقخصادي ، فؼال و يش

.نهؼذذ ي املشآث انصغرية و املخىسطت

IV

Table of Contents

Acknowledgment ........................................................................................................... I

Abstract ......................................................................................................................... II

III ........................................................................................................................ المستخلص

Table of Contents ......................................................................................................... IV

List of Figures .............................................................................................................. VI

List of Tables ............................................................................................................. VII

Abbreviations ............................................................................................................ VIII

Chapter 1 ........................................................................................................................ 1

1.1 Overview ........................................................................................................ 1 1.2 Statement of the problem ............................................................................... 1

1.3 Project Objectives .......................................................................................... 2 1.4 Methodology and Tools ................................................................................. 2 1.5 Thesis Layout ................................................................................................. 2

Chapter 2 ........................................................................................................................ 4

2.1 Supervisory Control and Data Acquisition (SCADA) ................................... 4 2.1.1 Historical Background ............................................................................. 4 2.1.2 SCADA: Concept..................................................................................... 5

2.1.4 SCADA: Software Archeticture .............................................................. 8 2.1.5 SCADA: Software Functionality ............................................................. 8

2.1.5 SCADA: Communication ...................................................................... 11 2.2 OLE for Process Control (OPC) .................................................................. 14

2.2.1 Overview ................................................................................................ 14 2.2.2 OPC standards ........................................................................................ 15

2.4 Process Modelling and Simulation ............................................................. 16 2.4.1 Systems and Experiments ...................................................................... 16

2.4.2 The Model Concept................................................................................ 17 2.4.3 Simulation .............................................................................................. 18 2.4.4 Kinds of Mathematical Models .............................................................. 19

Chapter 3 ...................................................................................................................... 22

3.1 Design Goals ................................................................................................ 22 3.1.1 Simplicity and ease of use ...................................................................... 22

3.1.2 Flexibility ............................................................................................... 22

3.1.3 Modular design ...................................................................................... 22 3.2 Design Overview ......................................................................................... 22 3.3 Design Tools ................................................................................................ 23

3.3.1 Simulink V7.2 ........................................................................................ 23 3.3.2 OPC Toolbox ......................................................................................... 24 3.3.3 Wonderware InTouch10 ........................................................................ 24 3.3.4 KepServerEx ......................................................................................... 25

3.4 Phase one: Process Simulation..................................................................... 26

V

3.4.1 Description of the Process ..................................................................... 26

3.4.2 Description of the simulation method .................................................... 27 3.4.3 Interfacing the simulation model to the OPC server ............................. 29

3.5 Phase Two: KepServer Configurations ........................................................ 32 3.6 Phase Three: HMI Design ............................................................................ 34

3.6.1 Description of HMI Windows design .................................................... 35 3.6.2 Tags Description .................................................................................... 37 3.6.3 Linking InTouch Tags to KEPServerEx ................................................ 39 3.6.4 Data Logging and Historical Trends ...................................................... 40 3.6.5 Scripts and logic ..................................................................................... 40

Chapter 4 ...................................................................................................................... 43

Testing and Results ...................................................................................................... 43

4.1 Process Simulation: ..................................................................................... 43 4.2 OPC Linking: ............................................................................................... 44

4.3 HMI Design ................................................................................................. 45

Chapter 5 ...................................................................................................................... 48

5.1 Conclusions .................................................................................................. 48 5.2 Discussion ................................................................................................... 48

5.3 Future Work ................................................................................................ 49

References .................................................................................................................... 50

Appendix A .................................................................................................................. 52

A.1 Modeling the process .................................................................................... 52

A.1.1 Gas Turbine ............................................................................................ 53 A.1.2 Economizer, Evaporator and Superheater .................................................. 54

A.1.3 Drum ...................................................................................................... 56 A.1.4 Steam Turbine ........................................................................................ 57

A.1.5 Inequality Constraints ............................................................................ 58 A.2 Simulation model: ........................................................................................ 60

Appendix B .................................................................................................................. 61

Appendix C .................................................................................................................. 65

C.1 Introduction .................................................................................................. 65 C.2 Designing a Project ...................................................................................... 66

VI

List of Figures

‎FIGURE 2.1: SCADA LAYOUT ERROR! BOOKMARK NOT DEFINED.6

‎FIGURE 2.2: A TYPICAL SCADA SYSTEM 7

‎FIGURE 2.3:GENERIC SCADA SOFTWARE ARCHITECTURE 8

‎FIGURE 2.4: POINT-TO-POINT (TWO STATIONS) 11

‎FIGURE 2.5: MULTI-POINT ARCHITECTURE 12

‎FIGURE 2.6: STORE AND FORWARD 12

‎FIGURE 2.7: TALK THROUGH REPEATERS 13

‎FIGURE 2.8: OPC CLIENT/SERVER RELATIONSHIP 14

‎FIGURE 2.9: GROUP/ITEM RELATIONSHIP 15

‎FIGURE 3.1: CONCEPTUAL DESIGN OF THE VIRTUAL PLANT ENVIRONMENT 23

‎FIGURE 3.2: COMPONENTS OF INTOUCH HMI 25

‎FIGURE 3.3: TOOLS USED IN THE DESIGN 26

‎FIGURE 3.4: COMPONENTS OF THE SIMULATED COMBINED CYCLE PROCESS 27

FIGURE 3.5: OPC CONFIGURATION DIALOG BOX 30

FIGURE 3.6: INTOUCH HMI CREATION, DEVELOPMENT AND EXECUTION 35

‎FIGURE 3.7: MAIN HMI WINDOW SNAPSHOT 37

‎FIGURE 3.8: TAGS TYPES IN INTOUCH 38

FIGURE 3.9: TAG DATA LOGGING AND HISTORICAL TRENDS 40

FIGURE 3.10: NUMERICAL INTEGRATION OF POWER OVER TIME 41

‎FIGURE 4.1: LINKING SIMULINK 45

‎FIGURE 4.2: SCREEN SNAPSHOT SIMULINK DATA VS HMI HISTORICAL TRENDS 46

‎FIGURE 5.1: ILLUSTRATION OF HISTORICAL TIEBACK METHOD 49

VII

List of Tables

TABLE 3.1: SUBSYSTEMS INPUTS/OUTPUTS 29

TABLE 3.2: LIST OF POSSIBLE ERRORS OR EVENTS 31

TABLE 3.3: CHANNEL SETTINGS 33

TABLE 3.4: DEVICE SETTINGS 33

TABLE 3.5: KEPSERVER TAGS 34

TABLE 3.6: LIST OF INTOUCH TAGS 39

VIII

Abbreviations

SCADA Supervisory Control and Data Acquisition

HMI Human Machine Interface

RTU Remote Terminal Unit

PLC Programmable Logic Control

MTU Master Terminal Unit

LAN Local Area Network

WAN Wide Area Network

IED Intelligent Electronic Devices

OPC OLE for Process Control

DDE Direct Data Exchange

OLE Object Linking and Embedding

ERP Enterprise Recourse Planning

MES Manufacturing Execution System

Chapter 1 Introduction

1

Chapter 1

Introduction

1.1 Overview

A control system is a collection of components working together under the direction

of some machine intelligence. Because the machine itself is making the routine

decisions, the human operator is freed to do other things. In many cases, machine

intelligence is better than direct human control because it can react faster, respond

more precisely and maintain an accurate log of the system‘s‎performance.

As a consequence of this fact the general trend in the process control industry is to

develop highly automated control systems with minimal human dependence. In these

systems the operator job is to monitor the process through some sort of a user

interface in which he can issue some supervisory control commands. With advances

in computer and communication technologies such systems became realizable.

SCADA (Supervisory Control and Data Acquisition) are the industry de facto

standard for such application.

SCADA and HMI(Human Machine Interface) systems have allowed a single operator

to monitor and control thousands of process control loops from a single station.

SCADA/HMI technologies became at the heart of any modern process control system.

1.2 Statement of the problem

There is a long history in instrumentation and process control of learning the hard way

by being thrown into an application. In general, the more mistakes that a person made,

the‎more‎that‎was‎learned.‎This‎―trial‎by‎fire‖‎is‎exciting but is hard on the people and

the processes. An alternative to this approach is the use of a virtual plant environment

that allow the user to get a hand-on experience to work on difficult scenarios that are

as difficult as the real ones.

There may be some reluctance to invest in development of such interactive dynamic

simulation mostly due to the high initial cost and maintenance of previous


2

implementations where the dynamic model had to be written from scratch and the

control system and displays had to be emulated by programmers.

1.3 Project Objectives

The objective of this project is to develop a virtual plant environment of a combined

cycle power plant using existing SCADA/HMI technologies and a state-of-the-art

modeling and simulation software.

The user of the system must be able to:

Run the HMI of the control system with the simulated process as if it was connected

to the real plant.

Easily modify the plant model in response to changes in the real plant.

1.4 Methodology and Tools

A modular approach is used to meet the specified objectives. The project is broken

into three major tasks:

Process simulation: simplified model of a combined cycle power plant is simulated

in the Matlab/Simulink environment.

HMI Design: Human Machine Interface is built using Wonderware InTouch software

package.

Linking the simulation to HMI using OPC technology: KEPServerEX is used as

the OPC server.

1.5 Thesis Layout

The thesis is organized as follows:

Chapter 2: In this chapter, the theoretical background needed throughout the project

is covered.

Chapter 3: This chapter deals with the system design in terms of design goals and

tools. Also, explanation of implementation method is presented.

Chapter 4: In this chapter, tests procedures and results obtained after system

implementation are discussed.

Chapter 5: Conclusions and recommended future work are presented in this chapter.


3

Appendix A: presents details of the plant model showing how it is simulated in

Simulink.

Appendix B: presents snapshots of various HMI screens.

Appendix C: presents a brief introduction to KEPServerEx software.

Chapter 2 Literature Review

4

Chapter 2

Literature Review

This chapter provides the necessary theoretical background for the project. It is

attained through examination of various textbooks and online resources.

2.1 Supervisory Control and Data Acquisition (SCADA)

SCADA (supervisory control and data acquisition) is a control technology that has

been developed for controlling geographically large processes. Pipelines, oil and gas

production facilities, electrical generation and transmission systems, and irrigation

systems are examples of processes that can be operated using this technology.[1]

2.1.1 Historical Background

With geographically smaller processes, it is practical for the human operator to visit

each of the process sensors to monitor the health of the process. In addition, it is

effective, if the process is small enough, for the operator to go to each valve or motor

that must be controlled and to make any necessary adjustments. Soon it was noticed

that even for small plants, the operator spent too much time walking and not enough

time operating. It became necessary to extend the reach of the operator. Control

systems were developed, first using pneumatic signalling, and later using electrical

signals, to bring the information from the process to the operator and to take the

operator‘s‎instructions‎to‎the‎valves‎and‎motors‎in‎the‎process.

The operation of geographically large processes still requires that sensors be

monitored and valves and motors be controlled. Before the development of SCADA,

telephones would be used to enable a field supervisor to instruct operators which

information to gather and which actuators to adjust. The operator often had to drive,

and sometimes to fly, from location to location in order to do so.

During the 1960s, improvements in communication technology were combined with

improvements in human– machine interface (HMI). This resulted in a system that

greatly extended the reach of the operator. With these technologies integrated


5

properly, the operator or supervisor could sit in a comfortable central location and

monitor the flow of oil through a pipeline located 15 miles away—or 1500 miles

away.

That technology was still not SCADA. Early systems were simple telemetry, with

communication in one direction, from field to control room. They still required that an

operator be dispatched to the field site to adjust the pressure or to turn a motor on or

off. The problem was that, although the communication system could reach a long

distance, there was nothing available at the remote site that was capable of

understanding and remembering any instructions. A latching relay could remember

the‎ simple‎ instruction‎ ―Close,‖‎ but‎ translating that instruction from the operator,

through the communication system, to the relay took the development of inexpensive

programmable devices. When microcomputers became available, it was possible to

build a machine that could understand the instruction from the radio, remember the

instruction, compare the instruction to the current situation, and drive the relay to the

proper position. Now the operator, sitting in a control room, could supervise the

process by monitoring the positions of switches and sending instructions to something

at the site to‎open‎and‎close‎relays.‎That‎―something,‖‎which‎later became known as

an RTU (remote terminal unit), was doing the actual control because it was hardwired

to the relay. It could also be hardwired to status switches on the field devices to

provide feedback to the operator that the device had moved to the required position,

allowing the operator to supervise the operation of the RTU control. [1]

2.1.2 SCADA: Concept

A SCADA (or supervisory control and data acquisition) system means a system

consisting of a number of remote terminal units (or RTUs) collecting field data

connected back to a master station via a communications system. The master station

displays the acquired data and also allows the operator to perform remote control

tasks as shown in Error! Reference source not found..

The accurate and timely data (normally real-time) allows for optimization of the

operation of the plant and process. A further benefit is more efficient, reliable and

most importantly, safer operations. This all results in a lower cost of operation

compared to earlier non-automated systems.


6

There is a fair degree of confusion between the definition of SCADA systems and

process control system. SCADA has the connotation of remote or distant operation.

The inevitable question is‎how‎far‎‗remote‘‎is‎– typically this means over a distance

such that the distance between the controlling location and the controlled location is

such that direct-wire control is impractical (i.e. a communication link is a critical

component of the system).

Figure 2.1: SCADA Layout

On a more complex SCADA system there are essentially five levels or hierarchies:

•‎Field‎level‎instrumentation‎and‎control‎devices

•‎Marshalling‎terminals‎and‎RTUs

•‎Communications‎system

•‎The‎master‎station(s)

•‎The‎commercial data processing department computer system

The RTU provides an interface to the field analog and digital signals situated at each

remote site.

The communications system provides the pathway for communications between the

master station and the remote sites. This communication system can be radio,


7

telephone line, microwave and possibly even satellite. Specific protocols and error

detection philosophies are used for efficient and optimum transfer of data.

The master station (and sub-masters) gather data from the various RTUs and generally

provide an operator interface for display of information and control of the remote

sites. In large telemetry systems, sub-master sites gather information from remote

sites and act as a relay back to the control master station.[2]

Figure 2.2: A Typical SCADA System


8

2.1.4 SCADA: Software Archeticture

The SCADA Software packages are multi-tasking and are based upon a real-time

database (RTDB) located in one or more servers. Servers are responsible for data

acquisition and handling (e.g. polling controllers, alarm checking, calculations,

logging and archiving) on a set of parameters, typically those they are connected to.

However, it is possible to have dedicated servers for particular tasks, e.g. data-logger

a SCADA architecture that is generic for the products that were evaluated. [3]

‎0Figure 2.3:Generic SCADA Software Architecture

2.1.5 SCADA: Software Functionality

a. Access Control

Users are allocated to groups, which have defined read/write access privileges to the

process parameters in the system and often also to specific product functionality.


9

b. HMI

SCADA softwares support multiple screens, which can contain combinations of

synoptic diagrams and text. They also support the concept of a "generic" graphical

object with links to process variables. These objects‎ can‎be‎ ―dragged‎and‎dropped‖‎

from a library and included into a synoptic diagram.

Most of the SCADA products that were evaluated decompose‎the‎process‎in‎―atomic‖‎

parameters (e.g. a power supply current, its maximum value, its on/off status, etc.) to

which a Tag-name is associated. The Tag-names‎ used‎ to‎ link‎ graphical‎ objects‘‎ to‎

devices can be edited as required. The products include a library of standard graphical

symbols, many of which would however not be applicable to the type of applications

encountered in the experimental physics community.

Standard windows editing facilities are provided: zooming, re-sizing, scrolling... On-

line configuration and customisation of the HMI is possible for users with the

appropriate privileges. Links can be created between display pages to navigate from

one view to another.

c. Trending

The products all provide trending facilities and one can summarise the common

capabilities as follows:

•‎the‎parameters‎to‎be‎trended‎in‎a‎specific‎chart can be predefined or defined on-line

•‎ a‎ chart‎ may‎ contain more than 8 trended parameters or pens and an unlimited

number of charts can be displayed (restricted only by the readability)

•‎ real-time and historical trending are possible, although generally not in the same

chart

•‎historical‎trending‎is‎possible‎for any archived parameter

•‎zooming‎and‎scrolling‎functions‎are‎provided

•‎parameter‎values‎at‎the‎cursor‎position‎can‎be displayed

The trending feature is either provided as a separate module or as a graphical object

(ActiveX), which can then be embedded into a synoptic display. XY and other

statistical analysis plots are generally not provided.

d. Alarm Handling

Alarm handling is based on limit and status checking and performed in the data

servers. More complicated expressions (using arithmetic or logical expressions) can

be developed by creating derived parameters on which status or limit checking is then


10

performed. The alarms are logically handled centrally, i.e., the information only exists

in one place and all users see the same status (e.g., the acknowledgement), and

multiple alarm priority levels (in general many more than 3 such levels) are

supported. It is generally possible to group alarms and to handle these as an entity

(typically filtering on group or acknowledgement of all alarms in a group).

Furthermore, it is possible to suppress alarms either individually or as a complete

group. The filtering of alarms seen on the alarm page or when viewing the alarm log

is also possible at least on priority, time and group. However, relationships between

alarms cannot generally be defined in a straightforward manner. Emails can be

generated or predefined actions automatically executed in response to alarm

conditions.

e. Logging/Archiving

The terms logging and archiving are often used to describe the same facility.

However, logging can be thought of as medium-term storage of data on disk, whereas

archiving is long-term storage of data either on disk or on another permanent storage

medium. Logging is typically performed on a cyclic basis, i.e., once a certain file size,

time period or number of points is reached the data is overwritten. Logging of data

can be performed at a set frequency, or only initiated if the value changes or when a

specific predefined event occurs. Logged data can be transferred to an archive once

the log is full. The logged data is time-stamped and can be filtered when viewed by a

user. The logging of user actions is in general performed together with either a user

ID or station ID. There is often also a VCR facility to play back archived data.

f. Automation

The majority of the products allow actions to be automatically triggered by events. A

scripting language provided by the SCADA products allows these actions to be

defined. In general, one can load a particular display, send an Email, run a user

defined application or script and write to the RTDB. The concept of recipes is

supported, whereby a particular system configuration can be saved to a file and then

re-loaded at a later date. Sequencing is also supported whereby, as the name indicates,

it is possible to execute a more complex sequence of actions on one or more devices.

Sequences may also react to external events. Some of the products do support an

expert system but none has the concept of a Finite State Machine (FSM).


11

2.1.5 SCADA: Communication

Another look at Figure 2.1 will show that data communication is at the centre of the

SCADA system. This long-distance communication, and the fact that it imposes the

need for supervisory control rather than direct control, is the element that

characterizes SCADA as different from other process control systems.

A brief description of communication architectures, philosophies and media used in

SCADA systems is given next.

2.1.5.1 Communication architectures

There are three main physical communication architectures that can be combined in

one communication system. They are:

Point-to-point architecture

This is the simplest configuration, where data is exchanged between two stations only.

One station can be setup as the master and one as the slave.

Figure 2.4: Point-to-point (two stations)

Multi-point architecture (Multiple stations)

In this configuration there is generally one master and multiple slaves. Normally data

is passed between the master and each of the slaves. If two slaves need to transfer data

between each other they would do so through the master that acts as arbitrator or

moderator. Alternatively it is possible for all the stations to act in a peer-to-peer

relationship. This is a more complex arrangement requiring sophisticated protocols to

handle collisions between two different stations wanting to transmit at the same time.


12

Figure 2.5: Multi-point Architecture

Relay station architecture

There are two possibilities here, namely store and forward or talk-through repeaters.

Store and forward relay operation can be a component of the other approaches

discussed above. This takes place where a station retransmits messages to another

station that is out of the range of the master station. This intermediate station is often

called a store and forward relay station.

Figure 2.6: Store and forward


13

Figure 2.7: Talk through repeaters

2.1.5.2 Communication philosophies

There are two commonly used options here, namely a polled approach or a contention

approach.

Polled (master–slave)

This can be used in a point-to-point or multi-point configuration and is probably the

simplest philosophy to use. The master is in total control of the communication

system and makes regular (repetitive) requests for data to be transferred to and from

each one of a number of slaves. The slaves do not initiate the transactions but rely on

the master.

Contention (peer-to-peer)

There is no controlling master and individual stations have to contend (compete) for

access to the transmission medium. In such an arrangement collisions are unavoidable

and stations have to contend with them.


14

2.2 OLE for Process Control (OPC)

2.2.1 Overview

An‎OPC‎―OLE‎(Object‎Linking‎and‎Embedding)‎for‎Process‎Control‖‎is‎a‎standard‎

mechanism that enables the communication and data exchanging between various

types of devices and control applications.

Usually OPC implemented as:

OPC Server which is a software application that acts as an API (Application

Programming Interface) or protocol converter. It allows Windows programs to

communicate with industrial hardware devices as PLC, or any data source such as a

database or User interface, and translate the data into the OPC client.

OPC Client which is a software application used to access (for reading and/or

writing) information provided by the OPC Server through the OPC standard (e.g.

HMI, historian, trending application etc).

Figure 2.8: OPC Client/Server Relationship

Each software or application developer was required to write a custom interface, or

server/driver, to communicate and exchange data with each one of the field devices.

This old technique have many problems because it requires to write driver for each

device‎ and‎ it‎ doesn‘t‎ support‎ the‎ change‎ of‎ a‎ device‎ which‎ will‎ leads‎ to‎ many‎

conflicts. OPC eliminates this requirement by defining a common, high performance

interface that permits this work to be done once, and then easily reused by HMI,

SCADA, Control and custom applications.


15

2.2.2 OPC standards

2.2.2.1 OPC DataAccess

At a high level, an OPC DataAccess Server is comprised of several objects: the

server, the group, and the item. The OPC server object maintains information about

the server and serves as a container for OPC group objects. The OPC group object

maintains information about itself and provides the mechanism for containing and

logically organizing OPC items. There are two types of groups, public and local.

Public is for sharing across multiple clients, local is local to a client.

Within each Group the client can define one or more OPC Items. The OPC Items

represent connections to data sources within the server. An OPC Item, from the

custom interface perspective, is not accessible as an object by an OPC Client.

Therefore, there is no external interface defined for an OPC Item. Associated with

each item is a Value, Quality and Time Stamp. Note that the items are not the data

sources - they are just connections to them.

Figure 2.9: Group/Item Relationship

2.2.2.2 OPC Alarm and Event Handling

These interfaces provide the mechanisms for OPC Clients to be notified of the

occurrence of specified events and alarm conditions. They also provide services

which allow OPC Clients to determine the events and conditions supported by an

OPC Server, and to obtain their current status.


16

Within OPC, an alarm is an abnormal condition and is thus a special case of a

condition. A condition is a named state of the OPC Event Server, or of one of its

contained objects, which is of interest to its OPC Clients. On the other hand, an event

is a detectable occurrence which is of significance to the OPC Server, the device it

represents, and its OPC Clients

2.2.2.3 OPC Historical Data Access

The OPC Historical Data Access is a standard used to retrieve and analyze historical

process data stored in (Process Data Archiver, database, or RTU).

There are several types of Historian servers:

•‎Simple‎Trend‎data‎servers.‎These‎servers‎provided‎little‎else‎then‎simple‎raw‎data‎

storage. (Data would typically be the types of data available from an OPC Data

Access server, usually provided in the form of a tuple [Time Value & Quality])

•‎ Complex‎ data‎ compression‎ and‎ analysis‎ servers.‎ These‎ servers‎ provide‎ data‎

compression as well as raw data storage. They are capable of providing summary data

or data analysis functions, such as average values, minimums and maximums etc.

They can support data updates and history of the updates. They can support storage of

annotations along with the actual historical data storage. [4]

2.4 Process Modelling and Simulation

2.4.1 Systems and Experiments

A system can be almost anything. A system can contain subsystems which are

themselves systems. A possible definition of system might be:

A system is an object or collection of objects whose properties we want to study.

An important property of systems is that they should be observable. Some systems are

also controllable in the sense that we can influence their behavior through inputs, i.e.:


17

•‎The‎inputs‎of‎a‎system‎are‎variables‎of‎the‎environment‎that‎influence‎the‎behavior‎

of the system. These inputs may or may not be controllable by us.

•‎The‎outputs‎of‎ a‎ system‎are‎variables‎ that‎ are‎ determined‎by‎ the‎ system‎and‎may‎

influence the surrounding environment.

In many systems the same variables act as both inputs and outputs. We talk about

acausal behavior if the relationships or influences between variables do not have a

causal direction, which is the case for relationships described by equations. For

example, in a mechanical system the forces from the environment influence the

displacement of an object, but on the other hand the displacement of the object

influences the forces between the object and environment. What is input and what is

output in this case is primarily a choice by the observer, guided by what is interesting

to study, rather than a property of the system itself.

2.4.2 The Model Concept

A‎model‎of‎a‎system‎is‎anything‎an‎―experiment‖‎can‎be‎applied‎to‎in‎order‎to‎answer‎

questions about that system.

This implies that a model can be used to answer questions about a system without

doing experiments on the real system. Instead we perform a kind of simplified

―experiments‖‎ on‎ the‎model,‎which‎ in‎ turn‎ can‎be‎ regarded‎ as‎ a‎ kind‎ of‎ simplified‎

system that reflects properties of the real system. In the simplest case a model can just

be a piece of information that is used to answer questions about the system. Given this

definition, any model also qualifies as a system. Models, just like systems, are

hierarchical in nature. We can cut out a piece of a model, which becomes a new

model that is valid for a subset of the experiments for which the original model is

valid. A model is always related to the system it models and the experiments it can be

subject‎ to.‎ A‎ statement‎ such‎ as‎ ―a‎ model‎ of‎ a‎ system‎ is‎ invalid‖‎ is‎ meaningless‎

without mentioning the associated system and the experiment. A model of a system

might be valid for one experiment on the model and invalid for another. The term

model validation always refers to an experiment or a class of experiment to be

performed.


18

2.4.3 Simulation

A simulation is an experiment performed on a model

If the mathematical model is represented in executable form in a computer,

simulations can be performed by numerical experiments, or in nonnumerical cases by

computed experiments. This is a simple and safe way of performing experiments, with

the added advantage that essentially all variables of the model are observable and

controllable. However, the value of the simulation results is completely dependent on

how well the model represents the real system regarding the questions to be answered

by the simulation.

Except for experimentation, simulation is the only technique that is generally

applicable for analysis of the behavior of arbitrary systems. Analytical techniques are

better than simulation, but usually apply only under a set of simplifying assumptions,

which often cannot be justified. On the other hand, it is not uncommon to combine

analytical techniques with simulations, i.e., simulation is used not alone but in an

interplay with analytical or semi-analytical techniques.

Reasons for Simulation

There are a number of good reasons to perform simulations instead of performing

experiments on real systems:

•‎Experiments‎are‎too‎expensive,‎too‎dangerous,‎or‎the‎system‎to‎be‎investigated‎does‎

not yet exist.

•‎ The‎ time‎ scale‎ of‎ the‎ dynamics of the system is not compatible with that of the

experimenter. For example, it takes millions of years to observe small changes in the

development of the universe, whereas similar changes can be quickly observed in a

computer simulation of the universe.

•‎ Variables‎ may‎ be‎ inaccessible.‎ In‎ a‎ simulation‎ all‎ variables‎ can‎ be‎ studied‎ and‎

controlled, even those that are inaccessible in the real system.

•‎ Easy‎ manipulation‎ of‎ models.‎ Using‎ simulation,‎ it‎ is‎ easy‎ to‎ manipulate‎ the‎

parameters of a system model, even outside the feasible range of a particular physical

system. For example, the

mass of a body in a computer-based simulation model can be increased from 40 to

500 kg at a keystroke, whereas this change might be hard to realize in the physical

system.


19

•‎ Suppression of disturbances. In a simulation of a model it is possible to suppress

disturbances that might be unavoidable in measurements of the real system. This can

allow us to isolate particular effects and thereby gain a better understanding of those

effects.

•‎ Suppression‎ of‎ second-order effects. Often, simulations are performed since they

allow suppression of second-order effects such as small nonlinearities or other details

of certain system components, which can help us to better understand the primary

effects.

2.4.4 Kinds of Mathematical Models

Different kinds of mathematical models can be characterized by different properties

reflecting the behavior of the systems that are modeled. One important aspect is

whether the model incorporates dynamic time-dependent properties or is static.

Another dividing line is between models that evolve continuously over time, and

those that change at discrete points in time. A third dividing line is between

quantitative and qualitative models.

Certain models describe physical distribution of quantities, e.g. mass, whereas other

models are lumped in the sense that the physically distributed quantity is

approximated by being lumped together and represented by a single variable, e.g. a

point mass.

Some phenomena in nature are conveniently described by stochastic processes and

probability distributions, e.g. noisy radio transmissions or atomic-level quantum

physics. Such models might be labeled stochastic or probability-based models where

the behavior can be represented only in a statistic sense, whereas deterministic models

allow the behavior to be represented without uncertainty. However, even stochastic

models can be simulated in a "deterministic" way using a computer since the random

number sequences often used to represent stochastic variables can be regenerated

given the same seed values.

Dynamic vs. Static Models

All systems, both natural and man-made, are dynamic in the sense that they exist in

the real world, which evolves in time. Mathematical models of such systems would be

naturally viewed as dynamic in the sense that they evolve over time and therefore


20

incorporate time. However, it is often useful to make the approximation of ignoring

time dependence in a system. Such a system model is called static. Thus we can

define the concepts of dynamic and static models as follows:

•‎A dynamic model includes time in the model. The word dynamic is derived from the

Greek word dynamis meaning force and power, with dynamics being the (time-

dependent) interplay between forces. Time can be included explicitly as a variable in

a mathematical formula, or be present indirectly, e.g. through the time derivative of a

variable or as events occurring at certain points in time.

•‎ A static model can be defined without involving time, where the word static is

derived from the Greek word statikos, meaning something that creates equilibrium.

Static models are often used to describe systems in steady-state or equilibrium

situations, where the output does not change if the input is the same. However, static

models can display a rather dynamic behavior when fed with dynamic input signals.

Continuous-Time vs. Discrete-Time Dynamic Models

There are two main classes of dynamic models: continuous-time and discrete-time

models. The class of continuous-time models can be characterized as follows:

• Continuous-time models evolve their variable values continuously over time.

The mathematical formulation of continuous-time models includes differential

equations with time derivatives of some model variables.

Many laws of nature, e.g. as expressed in physics, are formulated as differential

equations.

The second class of mathematical models is discrete-time models where variables

change value only at certain points in time:

• Discrete-time models may change their variable values only at discrete points in

time.

Discrete-time models are often represented by sets of difference equations, or as

computer programs mapping the state of the model at one point in time to the state at

the next point in time.

Discrete-time models occur frequently in engineering systems, especially computer-

controlled systems. A common special case is sampled systems, where a continuous-


21

time system is measured at regular time intervals and is approximated by a discrete-

time model. Such sampled models usually interact with other discrete-time systems

like computers. Discrete-time models may also occur naturally, e.g. an insect

population which breeds during a short period once a year; i.e., the discretization

period in that case is one year. [4]

Chapter 3 Description of design and implementation methodology

22

Chapter 3

Description of Design and Implementation

Methods

This chapter first goes through the main goals that the system is intentionally

designed to achieve. Then a description of system design and tools is provided

followed by detailed description of implementation method.

3.1 Design Goals

The proposed virtual plant design has taken into consideration the following goals:

3.1.1 Simplicity and ease of use

Many users tend to dislike text-based interfaces. Consequently, design should provide

graphical interface that can be easily accessed with least complexity for both users

and developers.

3.1.2 Flexibility

A dominant factor in reducing maintenance costs required in the virtual plant to

accommodate modification in the real plant. Hence, design should ensure flexibility

and ease of modification of the original plant.

3.1.3 Modular design

Deviding the system into several modules reduces development and debugging time.

3.2 Design Overview

Design of the virtual plant was divided into three phases: Process simulation, HMI

Design and OPC interfacing. In the first module a simplified model of a combined

cycle power plant is simulated in the Matlab/Simulink environment. The second


23

module is a Human Machine Interface built using Wonderware InTouch software

package. This two modules is linked together using an OPC interface implemented in

KEPServer EX software. The conceptual design of the virtual plant environment is

shown in figure 3.1.

HMI

OPC Server

Simulated Process

Model

Virtual Plant Environment

User

Developer

Figure 3.1: Conceptual design of the virtual plant environment

3.3 Design Tools

In this section a brief description of the tools used in the design is given justifying its

selection.

3.3.1 Simulink V7.2

Simulink, developed by The MathWorks, is a commercial tool for modeling,

simulating and analyzing multidomain dynamic systems. Its primary interface is a

graphical block diagramming tool and a customizable set of block libraries. It offers

tight integration with the rest of the MATLAB environment and can either drive

MATLAB or be scripted from it. Simulink is widely used in control theory and digital

signal processing for multidomain simulation and design. [5]

Simulink was chosen primarily for two reasons:

Its graphical based modeling makes it easy and efficient to build models.

http://en.wikipedia.org/wiki/The_MathWorks

http://en.wikipedia.org/wiki/Dynamic_systems

http://en.wikipedia.org/wiki/Visual_modeling

http://en.wikipedia.org/wiki/Library_%28computer_science%29

http://en.wikipedia.org/wiki/MATLAB

http://en.wikipedia.org/wiki/Control_theory

http://en.wikipedia.org/wiki/Digital_signal_processing




24

A number of blocksets are available for use with Simulink. One of these

blocksets the OPC blocksets(only available in Version 7.2 or later) greatly

facilitates the task of establishing a connection between Simulink and the OPC

server.

3.3.2 OPC Toolbox

OPC‎Toolbox™‎software‎is‎a‎collection‎of‎functions‎that‎extend‎the‎capability‎of‎the‎

MATLAB® environment, and blocks that extend the Simulink® simulation

environment. Using OPC Toolbox functions and blocks, we can acquire live OPC

data directly into MATLAB and Simulink, and write data directly to the OPC server

from MATLAB and Simulink.

When working in the Simulink environment, we can use blocks from the OPC

Toolbox block library to use live OPC data as inputs to our model and update the

OPC server with our model outputs. The OPC Toolbox block library includes the

capability of running Simulink models in pseudo real time, by slowing the simulation

to match the system clock. We can prototype control systems, provide plant

simulators, and perform optimization and tuning tasks using Simulink and the OPC

Toolbox block library [6].

3.3.3 Wonderware InTouch10

Wonderware InTouch is a software package used to develop and run SCADA/HMI

applications. The following figure shows the core components of the InTouch HMI

that is used to build and run applications.


25

Figure 3.2: Components of Intouch HMI[8]

As its name suggests, Application Manager is used to create and manage InTouch

applications. The application development environment, called WindowMaker,

includes a set of graphic and other development tools to build applications.

Applications are run using WindowViewer.

We have chosen InTouch for the next reasons:

o Wonderware InTouch is really easy to work with and enough powerful for

development of this application.

o Is possible to learn to work with InTouch in a short period of time.

3.3.4 KepServerEx

KEPServerEx is a 32-bit windows application that provides a means of bringing data

and information from a wide range of industrial devices and systems into client

applications on windows PC. KEPServerEx falls under the category of a "Server"

application. In the industrial market, it has usually come to mean the sharing of

manufacturing or production data between a variety of applications ranging from

human machine interface software and data historians, to large MES and ERP

applications.

Figure 3.3 shows were the tools fit in the design.


26

HMI

OPC Server

Simulated Process Model

Virtual Plant Environment

DD

E

User

Developer

Tag Name Dictionary

OPC Toolbox

Disc

Loging

Simulink

InTouch

KEPServerEX

Figure 3.3: Tools used in the design

3.4 Phase one: Process Simulation

A simplified model of a single-pressure combined cycle power plant was obtained

from [7]. Real time simulation was carried out in Simulink . Major process variables

were transferred to the OPC server via the OPC toolbox blockset.

3.4.1 Description of the Process

The single-pressure combined-cycle power plant model consists of six components: a

gas turbine, a steam turbine, a steam drum, a counter flow economizer, a natural

circulation evaporator and a counter flow superheater. The power plant and the

components of the mathematical model are shown in Figure 3.4.


27

Figure 3.4: Components of the simulated combined cycle process

For detailed description of each component governing equations and input/output

relations refer to appendix A.

3.4.2 Description of the simulation method

The simulated model is constructed using a modular approach in which each

component constitutes a subsystem in the model and each subsystem consists of

several subsystems. In other words the model is built using a bottom up method.

Subsystems in the bottom are built by using basic blocks such as integrators, sums,

gains and multipliers.

The model of the single-pressure combined-cycle power plant has a total number of

114 variables. With a total of 20 differential equations and 93 algebraic equations.


28

The DAE system has one degree of freedom. This degree of freedom is represented

by the control variable Ugt (fuel flow rate in the gas turbine). Figure 3.5 shows the

detailed Simulink model of the combined-cycle power plant. The various components

of the plant, e.g. gas turbine and superheater, have been grouped into subsystems to

eliminate screen clutter. Table 3.1 gives a description of each component(subsystem)

inputs and outputs.

Solver Parameters of the Simulink Model

The detailed simulation model is solved with a dynamic MATLAB/Simulink

simulation using the built-in solver ode45 (Dormand-Prince) with automatic variable

step sizes.

Subsystem Inputs Outputs

Gas Turbine Ugt: Fuel utilization Pgt: Power output of the turbine

𝑚 gas: mass flow rate of flue gases

leaving the turbine

Tgas: Temperature of flue gases leaving

the turbine

Superheater 𝑚 gas: mass flow rate of flue gases

leaving the turbine

Tgas_in: Temperature of flue gases

entering the superheater

𝑚 steam: mass flow rate of entering

the superheater

Pdrum: Pressure in the drum

Tdrum: Temperature of the drum.

Tsteam_ss: Temperature of the steam

leaving the superheater

Tgas_ss: Temperature of flue gases


Steam Turbine 𝑚 steam: mass flow rate of entering

the superheater


Tsteam_ss: Temperature of the steam

Psteam: Output power of the steam

turbine


29


Drum Tec_water: Temperature of water

leaving the economizer

𝑚 vap: mass flow rate of steam

evaporated in the evaporator

𝑚 steam: mass flow rate of entering the

superheater


Tdrum: Temperature in the drum.

∆ℎvap: heat of evaporation of water in

the drum

Evaporator 𝑚 gas: mass flow rate of flue gases

leaving the turbine

Tgas_ss: Temperature of flue gases


Tdrum: Temperature in the drum.

∆ℎvap: heat of evaporation of

water in the drum

Tgas_evap: Temperature of flue gases

leaving the evaporator

𝑚 vap: mass flow rate of steam

evaporated in the evaporator

Economizer 𝑚 gas: mass flow rate of flue gases

leaving the turbine

Tgas_evap: Temperature of flue

gases leaving the evaporator

𝑚 feedwater: mass flow rate of

feedwater is assumed to equal

𝑚 steam


Texhaust_gas: Temperature of flue gases

leaving the system

Tec_water : Temperature of the water

heated in the economizer..

Table 3.1: Subsystems inputs/outputs

3.4.3 Interfacing the simulation model to the OPC server

Connection to the OPC server (KEPServerEX) is established using mainly three

blocks OPC configuration, OPC read and OPC write.


30

OPC Configuration

The OPC Configuration block defines the OPC clients to be used in a model,

configures pseudo real-time behavior for the model, and defines behavior for OPC

errors and events.

The block has no input ports. One optional output port displays the model latency

(time spent waiting in each simulation step to achieve pseudo real-time behavior). We

cannot place more than one OPC Configuration block in a model. If we attempt to do

so, an error message appears, and the second OPC Configuration block becomes

disabled. Double clicking the block opens the dialog box shown in figure 3.5.

Figure 3.5: OPC configuration dialog box

In this dialog box several options are present:

Configure OPC Clients


31

Opens the OPC Client Manager for this model. Each model has a list of clients

associated with it. These clients are used during the simulation to read or write data to

an OPC server.

Error control

Defines actions that Simulink software must take when OPC-specific errors and

events are encountered. The available actions are to produce an error and stop the

simulation, produce a warning and continue the simulation, or ignore the error or

event.

The following table 3.2 describes each error or event.

Table 3.2: List of possible errors or events

Pseudo real-time simulation

Allows you to configure options for running the simulation in pseudo real time. When

Enable pseudo real-time simulation is checked, the model execution time matches the

system clock as closely as possible by slowing down the simulation appropriately.

The Speedup setting determines how many times faster than the system clock the

simulation runs. For example, a setting of 2 means that a 10-second simulation will


32

take 5 seconds to complete. Note that the real-time control settings do not guarantee

real-time behavior. If the model runs slower than real time, a pseudo real-time latency

violation error occurs. We can control how Simulink responds to a pseudo real-time

latency violation using the settings in the Error control pane. We can also output the

model latency using the Show pseudo real-time latency port setting.

When checked, the pseudo real-time latency (in seconds) is output from the block.

Pseudo real-time latency is the time spent waiting for the system clock during each

step. If this value is negative, the simulation runs slower than real time, and the

behavior defined in the Pseudo real-time violation setting determines the action that

Simulink takes.

OPC Read

The OPC Read block reads data from one or more items on an OPC server. The read

operation takes place synchronously (from the cache or from the device) or

asynchronously (from the device). The block outputs the values (V) of the requested

items in the first output, and optionally outputs the quality IDs (Q) and the time

stamps (T) associated with each data value in additional outputs. The time stamp may

be output as a serial date number (real-world time), or as the number of seconds from

the start of the simulation (simulation time). The V,Q,T triple presented at the output

ports is the last known data for each of the items read by the block. Use the time

stamp output to determine when a sample last changed.

OPC Write

The OPC Write block writes data to one or more items on an OPC server. The write

operation takes place synchronously or asynchronously. Each element of the input

vector is written to the corresponding item in the Item ID list defined for the

OPCWrite block.

3.5 Phase Two: KepServer Configurations

This type of OPC servers supports the use of multiple communications drivers

simultaneously. Each protocol or driver is referred to as a Channel.


33

In our design we have one channel which refers to the communication with the

process which is modeled in the MATLAB/Simulink Each channel has its own

settings this settings shown in the table below.

Channel name Channel1

Device driver Simulator

Optimization

control method

write only the

latest value for all

tags

Table 3.3: Channel settings

Within each channel there could be many devices. In our design we have one device

which must be assigned a name, ID and model. The device name is a user defined

logical name for the device. Since the selected device may be a part of a network we

have to select the device ID.

These above settings are shown in the table below

After initialization the channel and the device then we can start defining the tags. This

is the area where we define the variables associated with each device. For each tag we

must define its name, address, data type, the update rate and its accessibility

(read/write or read only).

Tag name Address Accessibility Scan rate /ms Description

T_GAS_OUT_SH K3500 read/ write 100 temperature of gas out

from super heater

T_GAS_OUT K8500 read/ write 100 temp of gas out from

evaporator

The device name

nice

Device id

1

The device model

16 bit device

Table 3.4: Device settings


34

T_GAS_IN K5000 read/ write 100 temperature of gas out

from gas turbine

T_EXHAUST_GAS K6500 read/ write 100 Temperature of gas out

from economizer

T_EC_WATER K4500 read/ write 100 temperature of the

water out from

economizer

T_DRUM K1500 read/ write 100 Temperature of steam

out from the drun

P_TOTAL K5500 read/ write 100 The total generated

power from the plant

P_ST K3000 read/ write 100 The generated power

from the steam turbine

P_GT K1000 read/ write 100 The generated power

from the gas turbine

P_DRUM K7000 read/ write 100 Pressure of steam out

from the drum

M_STEAM_SG K9500 read/ write 100 flow rate of steam out

from evaporator

M_STEAM_AB K6000 read/ write 100 flow rate of steam out

from drum

M_GAS K4000 read/ write 100 flow rate of gas out

from gas turbine

U_GT K0000 Read only 100 The input fuel

percentage

T_STEAM_OUT K9000 read/ write 100 temperature of steam

out from the

superheater

Table 3.5: KEPServer Tags

3.6 Phase Three: HMI Design

The human machine interface is designed and implemented using Wonderware

InTouch software package. Creating HMIs in Intouch is carried out in three steps:

i. Creating the application using InTouch application manager.

ii. Developing the application using InTouch window maker.

iii. Running the application using InTouch window viewer.

InTouch Application Manager manages most global tasks such as creating, deleting,

and modifying InTouch applications. Application Manager shows a list of current

InTouch applications. You select an application from the list to open in

WindowMaker or WindowViewer.


35

Figure 3.6: Intouch HMI creation, development and execution

WindowMaker is used to create the visual interface used by operators to view and

manage the processes. An InTouch interface shows data from and writes data back to

the process environment. The following subsection shows in some detail how the

HMI is developed in WindowMaker.

WindowViewer is the run-time environment for InTouch applications. Based upon

application‘s‎ requirements,‎ properties‎ that‎ determine‎ the‎ visual‎ appearance‎ and‎

operational characteristics of WindowViewer can be configured.

3.6.1 Description of HMI Windows design

To achieve simplicity and ease of use the HMI is designed as a group of interactive

windows. Each window displays some process variables and allows some supervisory

control tasks. A brief description of each window follows.

Main window

The main window is a mimic display of the whole plant. It allows the operator

to monitor all of the process. It displays the value of the generated power from

each one of the two turbines (gas turbine or steam turbine), the total generated

power by the plant and the total energy per hour. It also displays a real time

trend that allows the user to trace the relation between the fuel input to the

plant and the total power generated.


36

Gas turbine

This window allows the user to control and set the value of the fuel

percentage that enters the gas turbine. Also, it displays temperature and mass

flow rate of gases leaving the turbine.

Drum

This window is designed to monitor the flow rate, temperature and pressure of

the steam leaving the drum to the super heater.

Economizer

This window is designed to monitor the temperature of the pre-heated water

before entering the steam generator and the temperature of the exhaust gases

leaving the plant.

Super heater

This window is designed to monitor the temperature of the steam leaving the

super heater to the steam turbine.

Evaporator

This window is designed to monitor the flow rate and the temperature of the

steam leaving the steam generator to the drum.

Historical trend

This window displays a historical trend of fuel utilization and total power

output. It also, allows the user to calculate the average fuel and the average

generated power in a specified time interval.

Figure 3.7 shows the main windoe. A snapshot of each window is available in

appendix B.


37

Figure 3.7: Main HMI window snapshot

3.6.2 Tags Description

A tag represents a data item in an InTouch application. Tags are created for those

process components whose properties we want to monitor or control with the

application. [6]

We assign the name and type of tags with the Tagname Dictionary. For some types of

tags, there are other options in the Tagname Dictionary to specify additional

properties of tags. For example, I/O type tags include additional options to specify the

connection to a remote data source.

We‎can‎assign‎our‎application‘s‎ tags‎ to‎ four‎different‎ types‎based‎upon‎ the‎process‎

data associated with the tag. The following figure shows the Tagname Dictionary

includes specific types of tags for integer, real, discrete, or message data. The

Tagname Dictionary includes data types for memory, I/O, and indirect tags.


38

Figure 3.8: Tags types in InTouch

A list of all tags defined is given in table 3.6.

Tag name Tag type External/Internal Access name

T_GAS_OUT_SH I/O Real External KEPServerEX_FS

T_GAS_OUT I/O Real External KEPServerEX_FS

T_GAS_IN I/O Real External KEPServerEX_FS

T_EXHAUST_GAS I/O Real External KEPServerEX_FS

T_EC_WATER I/O Real External KEPServerEX_FS

T_DRUM I/O Real External KEPServerEX_FS

P_TOTAL I/O Real External KEPServerEX_FS

P_ST I/O Real External KEPServerEX_FS

P_GT I/O Real External KEPServerEX_FS

P_DRUM I/O Real External KEPServerEX_FS

M_STEAM_SG I/O Real External KEPServerEX_FS

M_STEAM_AB I/O Real External KEPServerEX_FS

M_GAS I/O Real External KEPServerEX_FS

U_GT I/O Real External KEPServerEX_FS

T_STEAM_OUT I/O Real External KEPServerEX_FS

AvgFuel Memory Real Internal -

AvgPower Memory Real Internal -

Process


39

AvgValue Memory Real Internal -

Historical HistTrend Internal -

HistTrend HistTrend Internal -

HistTrendPenScale Memory Integer Internal -

MWhr Memory Real Internal

Table 3.6: List of InTouch Tags

When WindowViewer starts an application, it reads the tags from the development

repository and places them into run-time memory. The InTouch application

communicates with the tags placed into run-time memory using animation links or

scripts. The InTouch application tracks the current values and other status information

from the component properties assigned to tags.

3.6.3 Linking InTouch Tags to KEPServerEx

Wonderware provides several ways to connect to third party servers like

KEPServerEX. At the core of all Wonderware connectivity is FastDDE and

SuiteLink. FastDDE and SuiteLink allow Wonderware applications such as InTouch

to receive data from servers like KEPServerEX. In our design we used FastDDE to

connect InTouch to KEPServerEx.

DDE connections consist of three components, an Application name, a Topic, and an

Item. When connecting to KEPServerEX via Fastdde the Application name will

always‎be‎―Servermain‖.‎This‎name‎is‎automatically‎defined‎in‎the‎server‎and‎cannot‎

be changed for Fastdde/Suitelink connections. There are two ways to reference the

Topic component. The preferred method to reference the DDE Topic is using the

Alias Map feature of the server. The Alias Map is a special feature that simplifies the

use of server data in DDE applications. It provides a way to assign simple alias names

to complex tag references (this is especially useful in client applications that limit the

size of tag address paths). [8]

In our design we have used FastDDE protocol to link InTouch tags to KEPServer.


40

3.6.4 Data Logging and Historical Trends

While an InTouch application is running, its tag values can be logged and

permanently saved. We can use this log data to create historical trend graphs that

show some aspect plant processes over time. [10]

Figure 3.9 below illustrates data logging and historical trend used in our design. Tag

data of plant total power outtput and input fuel utilization are saved to historical log

files.‎ The‎ InTouch‎ Historical‎ Logger‎ writes‎ a‎ log‎ entry‎ each‎ time‎ a‎ tag‘s‎ value‎

changes more than its specified log deadband range.

Historical

Logger

Plant Total

Output

Power

Plant Fuel

Utilization

WindowViewr Run-Time Environment

LGH

IDX

Historical

Trend

Historical Log Files

Disc

Figure 3,9: Tag Data Logging and Historical Trends

The InTouch HMI creates two log files. One file contains logged data stored in a

proprietary format. The other file is an index to the data.

A daily logging cycle begins and ends at midnight. The Historical Logger writes the

last entries to the active log files at midnight and archives them. Two new files are

created for the next day and data is logged to them.

Log files are saved for a specified number of days. Log files that are older than the

retention period are deleted.

3.6.5 Scripts and logic

The InTouch script language is used to automate repetitive functionality within an

application.‎ We‎ use‎ WindowMaker‘s‎ Script‎ Editor‎ dialog‎ box‎ to‎ create‎ and‎ edit‎

scripts.

There are seven types of scripts and many built-in script functions available. The

seven types of scripts are defined by what causes them to execute. For example,


41

application scripts execute when an application starts, stops, or continues running.

Data change scripts execute when a certain item of data changes. Window scripts

execute when a window opens, closes, or remains open.

We used an application script to calculate the total energy in MW.hr generated from

the plant.

Since energy is calculated by integrating power over time, the basic idea of this script

is to numerically integrate power over time. The script is triggered every 100 mS. It

samples the total power output and multiply it by the equivalent of 100mS in hours.

100mS

Time

Power

Figure 3.10: Numerical integration of power over time by application script

Script:

MWhr = MWhr+((0.1 / 3600) * P_TOTAL);


42

Chapter 4 Testing and Results

43

Chapter 4

Testing and Results

As stated earlier the project is divided into three phases. Each phase implementation is

tested and verified separately then the system was tested as whole. In this chapter

testing procedure, results and source of encountered errors for each phase

implementation is presented.

4.1 Process Simulation:

Two types of tests were carried to verify the integrity of the simulation model:

1. Subsystems test

Test procedure: examine each subsystem outputs under some realistic

constant inputs.

Test objective: detects errors in translating a‎component‘s‎governing‎

equations into Simulink blocks.

Test Results: In some components, errors were detected by observing

unrealistic outputs such as negative temperatures or pressures. Because

of the modular nature of subsystems such errors were easily corrected

by‎revising‎the‎simulink‎model‎and‎comparing‎it‎to‎the‎component‘s‎

governing equations.

2. Overall model test

Test procedure: compare the steady state total power under maximum

fuel input with the value stated in [9].

Test objective: Verify the integrity of the model.

Test Results: the steady state total power output of the plant was

found to be as described in [9].


44

4.2 OPC Linking:

In this phase tags was defined to contain important process variables.

Test procedure: Show the tags values using OPC quick client (a

testing tool in KEPServer and compare it to corresponding process

variables in Simulink.

Test objective: Verify the integrity of KEPServer tags linking to

Simulink.

Test Results: Errors were detected duo to duplication of tags addresses

in KEPServer. These errors were corrected by choosing different

addresses for each tag as shown in table 3.5.

(a)


45

(b)

Figure 4.1: Linking Simulink (a) to OPC server (b) showing identical results

4.3 HMI Design

HMI screens is shown in appendix B. Two tests to verify connection to the

OPC Server and integrity of historical data logs.

1. Connection Test

Test procedure: To set values of tags manually in KEPServer and

display corresponding InTouch tags.

Test objective: is to detect errors in InTouch‘s‎Tagname‎dictionary

and to verify connection integrity.

Test Results: although some errors were encountered because of

incorrect tags types‘ definition, errors were debugged and integrity was

assured.

2. Integrity of Historical data logs

Test procedure: To compare historical data logged by InTouch

historical data loggerand displayed in historical rend with

corresponding Simulink variables using the scope block.


46

Test objective: Verify the integrity of data logging.

Test Results: Historical trend and scope graphs were found to be

identical.

(a)

(b)

Figure 4.2: Screen snapshot that shows: (a) Simulink scope data (b) HMI historical Trends


47

Chaprer 5 Conclusion and Future Work

48

Chapter 5

Conclusions and Future Work

5.1 Conclusions

By the end of this project, virtual plant environment of a combined cylcle power plant

was successfully designed and implemented using existing SCADA/HMI

technologies and general purpose simulation software. Project objectives described in

section 1.3 was achieved.

Simulation model of the plant was built in Simulink simulation program.

Human machine interface to the simulated plant was developed using InTouch

software package.

The simulated plant was linked to its HMI using OPC technology.

5.2 Discussion

The traditional alternative to the solution presented in this project is to build

the whole virtual plant from scratch. In this method extensive programming

effort in building the simulation engine and emulating the control system HMI

screens is needed.

The extensive programming needed results in a very high initial cost. And

make it very difficult to update previous implementation of the virtual plant

with new modifications in the real plant.

On the other hand our solution uses existing technologies that is already

installed in any modern plant. This considerably reduces the cost of

implementing the virtual plant.

Chaprer 5 Conclusion and Future Work

49

Ease of new approach means that virtual plant environment is not restricted to

large or complex plants but can be implemented for much smaller

applications.

The graphical windows environment of the simulation program and HMI

means that the average engineer can run or modify the virtual plant.

5.3 Future Work

The method used in this project depends on the simulation model of the plant. When

developing a virtual plant such model may already exists (it may be used in the design

process) but in some cases it may be very difficult to obtain such model. A solution to

this difficulty is to use data logs from historical data servers (exist in any modern

plant). In this method the historical system states is tied back to the virtual plant to

emulate plant operation. First, current input state specified by the virtual plant

operator is captured. Then historical data logs are searched. The historical output

corresponding to the closest match found is sent back to the virtual plant through a

suitable delay in a tieback model.

Future work should be focused on integrating the tie back method to the system to

enhance usability and to reduce costs of modeling and simulation.

Historiacal Data

Virtual Plant

Environment

HMI

Search

Engine

Tieback delay

model

Dynamic

Simulation

LOG

LOG

LOG

Figure 5.1: Illustration of historical tieback method

References

50

References

[1] BOYER, S. A. 3.9 SCADA—Supervisory Control and Data Acquisition.

[book auth.] Béla G. Lipták. INSTRUMENT ENGINEERS’ HANDBOOK:

Process Software and Digital Networks. s.l. : ISA Press, Third Edition.

[2] Bailey, David and Wright, Edwin. Practical SCADA for Industry. Oxford :

Newnes, 2003.

[3] What is SCADA ? Daneels, A. and W.Salter. Geneva : CERN, 1999.

[4] OPC Overview. [Online] October 27, 1998.

http://www.opcfoundation.org/DownloadFile.aspx/General/OPC%20Overvie

w%201.00.pdf?RI=1.

[5] Fritzson, Peter. Principles of Object-Oriented Modelling and Simulation

with Modelica 2.1. s.l. : Wiley-IEEE Press, 2003. ISBN 0-471-471631.

[6] Simulink. [Online] http://en.wikipedia.org/wiki/Simulink.

[7] OPC Toolbox™ 2 User's Guide. s.l. : The MathWorks, Inc., 2008.

[8] InTouch® HMI Concepts and Capabilities Guide. s.l. : Invensys Systems,

Inc.,2007.

[9] Jockenhövel, Tobias. Dynamic Optimization of Complex Power Plants and

Chemical Processes. Berlin : s.n., 2004.

[10] KEPServerEX Client Connectivity Guide . s.l. : Kepware Technologies, 2001.

[11] InTouch® HMI Data Management Guide. s.l. : Invensys Systems Inc., 2007.

[12] Love, Jonathan. Process Automation Handbook. s.l. : Springer, 2007.

References

51

[13] Modern SCADA Systems for Oil Pipelines. Trung, Duong. s.l. : IEEE. Paper

No. PCIC-95-32.

Appendix A Modeling and Simulating the Process

52

Appendix A

Modeling and simulating the process

In this appendix governing equation of each process component is presented followed

by its corresponding Simulink.

A.1 Modeling the process

The single-pressure combined-cycle power plant model consists of six components: a

gas turbine, a steam turbine, a steam drum, an economizer, a natural circulation

evaporator and a superheater. The following figure shows the overall process

components.


53

A.1.1 Gas Turbine

The gas turbine model is based on siemens V84.3 gas turbine which has adjustable

guide vanes that allow about 60 % to 100 % of power to be generated with an almost

constant exhaust gas temperature Tgt, out . The exhaust gas temperature Tgt, out [ºC] and

the exhaust gas mass flow rate 𝑚 gas can be expressed as functions of the gas turbine

power Pgt or gas turbine fuel flow ugt:

𝑚 𝑔𝑎𝑠 = 303.401 if ugt ≤ 0.5

260.058ugt + 173.37 if 0.5 < ugt ≤ 1 (1)

𝑇𝑔𝑡 ,𝑜𝑢𝑡 = 517𝑢𝑔𝑡 + 29

550 (2)

The power of the gas turbine Pgt is given by


54

Pgt= ugt Pgt,max (3)

With Pgt,max = 170 MW

Simulink model is shown below.

A.1.2 Economizer, Evaporator and Superheater

The models for the economizer, evaporator and superheater are discretized spatially in

six sections For each section (i) in the economizer (ec), evaporator (steam generator

sg) and superheater (sh), a dynamic energy balance is formulated as:

1

𝑁𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑚𝑒𝑐 ,𝑠𝑡𝑒𝑒𝑙 𝑐𝑝 ,𝑠𝑡𝑒𝑒𝑙

𝑑𝑇 𝑒𝑐 ,𝑠𝑡𝑒𝑒𝑙 ,𝑖𝑑𝑡

= 𝑄 𝑒𝑐 ,𝑔𝑎𝑠−𝑠𝑡𝑒𝑒𝑙 ,𝑖 − 𝑄 𝑒𝑐 ,𝑠𝑡𝑒𝑒𝑙 −𝑤𝑎𝑡𝑒𝑟 ,𝑖 (4)

1

𝑁𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑚𝑠𝑔 ,𝑠𝑡𝑒𝑒𝑙 𝑐𝑝 ,𝑠𝑡𝑒𝑒𝑙

𝑑𝑇 𝑠𝑔 ,𝑠𝑡𝑒𝑒𝑙 ,𝑖

𝑑𝑡= 𝑄 𝑠𝑔 ,𝑔𝑎𝑠−𝑠𝑡𝑒𝑒𝑙 ,𝑖 −𝑄 𝑠𝑔 ,𝑠𝑡𝑒𝑒𝑙 −𝑤𝑎𝑡𝑒𝑟 ,𝑖 (5)

1

𝑁𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑚𝑠ℎ ,𝑠𝑡𝑒𝑒𝑙 𝑐𝑝 ,𝑠𝑡𝑒𝑒𝑙

𝑑𝑇 𝑠ℎ ,𝑠𝑡𝑒𝑒𝑙 ,𝑖𝑑𝑇

= 𝑄 𝑠ℎ ,𝑔𝑎𝑠−𝑠𝑡𝑒𝑒𝑙 ,𝑖 − 𝑄 𝑠ℎ ,𝑠𝑡𝑒𝑒𝑙−𝑠𝑡𝑒𝑎𝑚 ,𝑖 (6)

Where Nelement = 6, mec, steel, msg,steel and msh, steel are the masses of the heat exchanger

units and cp, steel = 0.6 kJ kg−1

K−1

is the specific heat capacity of steel.

Component Surface

A

Component

mass msteel

Heat transfer coefficient

U [W m−2 K−1]

Economizer 20,000

m2

60,000 kg Gas-Steel 30

Steel-Water 500

Evaporator 20,000

m2


Steel-Water 500

Superheater 30,000

m2


Steel-Steam 500


55

Uniform temperatures in each element i and constant heat transfer coefficients Ugas-

steel, Usteel-steam and Usteel-water are assumed. The heat flow rates 𝑄 are calculated for each

unit j

which belongs to the set J={ j | j = sh, sg, ec} and for each element i:

𝑄 𝑗 ,𝑔𝑎𝑠−𝑠𝑡𝑒𝑒𝑙 ,𝑖 = 1

𝑁𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑈𝑗 ,𝑔𝑎𝑠−𝑠𝑡𝑒𝑒𝑙 𝐴𝑗 𝑇𝑗 ,𝑔𝑎𝑠 ,𝑖 − 𝑇𝑗 ,𝑠𝑡𝑒𝑒𝑙 ,𝑖 (7)

and on the water-steam side by the following equations:

𝑄 𝑒𝑐 ,𝑠𝑡𝑒𝑒𝑙−𝑤𝑎𝑡𝑒𝑟 ,𝑖 = 1

𝑁𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑈𝑒𝑐 ,𝑠𝑡𝑒𝑒𝑙 −𝑤𝑎𝑡𝑒𝑟 𝐴𝑒𝑐 𝑇𝑒𝑐 ,𝑠𝑡𝑒𝑒𝑙 ,𝑖 − 𝑇𝑒𝑐 ,𝑤𝑎𝑡𝑒𝑟 ,𝑖 (8)

𝑄 𝑠𝑔 ,𝑠𝑡𝑒𝑒𝑙 −𝑤𝑎𝑡𝑒𝑟 ,𝑖 = 1

𝑁𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑈𝑠𝑔 ,𝑠𝑡𝑒𝑒𝑙 −𝑤𝑎𝑡𝑒𝑟 𝐴𝑠𝑔 𝑇𝑠𝑔 ,𝑠𝑡𝑒𝑒𝑙 ,𝑖 − 𝑇𝑑𝑟𝑢𝑚 (9)

𝑄 𝑠ℎ ,𝑠𝑡𝑒𝑒𝑙 −𝑠𝑡𝑒𝑎𝑚 ,𝑖 = 1

𝑁𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑈𝑠ℎ ,𝑠𝑡𝑒𝑒𝑙 −𝑠𝑡𝑒𝑎𝑚 𝐴𝑠ℎ 𝑇𝑠ℎ ,𝑠𝑡𝑒𝑒𝑙 ,𝑖 − 𝑇𝑠ℎ ,𝑠𝑡𝑒𝑎𝑚 ,𝑖 (10)

The temperatures of the exhaust gas of each section i in each unit j are calculated

implicitly:

𝑄 𝑗 ,𝑔𝑎𝑠−𝑠𝑡𝑒𝑒𝑙 ,𝑖 = 𝑐𝑝 ,𝑔𝑎𝑠𝑚 𝑔𝑎𝑠 𝑇𝑗 ,𝑔𝑎𝑠 ,𝑖−1 − 𝑇𝑗 ,𝑔𝑎𝑠 ,𝑖 (11)

with Cp, gas = 1.1 kJ kg−1

K−1

all other water and steam temperatures of the economizer

and the superheater are calculated implicitly:

𝑄 𝑒𝑐 ,𝑠𝑡𝑒𝑒𝑙 −𝑤𝑎𝑡𝑒𝑟 ,𝑖 = 𝑐𝑝 ,𝑒𝑐 ,𝑤𝑎𝑡𝑒𝑟 ,𝑖𝑚 𝑤𝑎𝑡𝑒𝑟 𝑇𝑒𝑐 ,𝑠𝑡𝑒𝑒𝑙 ,𝑖 − 𝑇𝑒𝑐 ,𝑤𝑎𝑡𝑒𝑟 ,𝑖+1 (12)

𝑄 𝑠ℎ ,𝑠𝑡𝑒𝑒𝑙 −𝑠𝑡𝑒𝑎𝑚 ,𝑖 = 𝐶𝑝 ,𝑠ℎ ,𝑠𝑡𝑒𝑎𝑚 ,𝑖𝑚 𝑠𝑡𝑒𝑎𝑚 𝑇𝑠ℎ ,𝑠𝑡𝑒𝑒𝑙 ,𝑖 − 𝑇𝑠ℎ ,𝑠𝑡𝑒𝑎𝑚 ,𝑖+1 (13)

The specific heat capacities in (12,13) are calculated using the external property

functions:

𝑐𝑝 ,𝑒𝑐 ,𝑤𝑎𝑡𝑒𝑟 .𝑖 = 𝑐𝑝 𝑇𝑒𝑐 ,𝑤𝑎𝑡𝑒𝑟 ,𝑖 ′𝑃𝑑𝑟𝑢𝑚

𝑐𝑝 ,𝑠ℎ ,𝑠𝑡𝑒𝑎𝑚 ,𝑖 = 𝑐𝑝 𝑇𝑠ℎ ,𝑠𝑡𝑒𝑎𝑚 ,𝑖′𝑃𝑑𝑟𝑢𝑚

(14)

Note that the steam temperature is assumed to be equal to the drum

temperature for all sections i in the evaporator.


56

Note that pressure drops have been neglected in all heat exchangers, so that

pec, water, i = pdrum = psh, steam, i

A perfect control of the liquid level in the drum is assumed such that

𝑚 steam = 𝑚 feed

A.1.3 Drum

The model of the drum takes steam storage into account. Assuming a constant density

and a constant storage capacity of Cdrum = 275 kg bar−1

, the steam mass balance

around the drum can be written as a differential equation of the drum pressure pdrum:

𝑑𝑃 𝑑𝑟𝑢𝑚𝑑𝑡

= 1

𝐶𝑑𝑟𝑢𝑚 𝑚 𝑣𝑎𝑝 −𝑚 𝑠𝑡𝑒𝑎𝑚 −𝑚 𝑎𝑝𝑝𝑟𝑜𝑎𝑐 ℎ (15)

With 𝑚 vap as the steam mass flow evaporated in the evaporator and 𝑚 steam as the

steam flow to the steam turbine. The mass flow rate 𝑚 approach is the steam rate to be

condensed to heat the water coming from the economizer with 𝑄 approach up to the

saturation temperature Tdrum:

𝑄 𝑎𝑝𝑝𝑟𝑜𝑎𝑐 ℎ = 𝑐𝑝 ,𝑒𝑐 ,𝑤𝑎𝑡 𝑒𝑟 ,1𝑚 𝑠𝑡𝑒𝑎𝑚 𝑇𝑑𝑟𝑢𝑚 − 𝑇𝑒𝑐 ,𝑤𝑎𝑡𝑒𝑟 ,1 (16)

𝑚 𝑎𝑝𝑝𝑟𝑜𝑎𝑐 ℎ =𝑄 𝑎𝑝𝑝𝑟𝑜𝑎𝑐 ℎ

∆ℎ𝑣𝑎𝑝 (17)

The mass flow rate of the live steam is a function of the difference between the

pressure in the drum pdrum and the pressure in the condenser pcond:

𝑚 𝑠𝑡𝑒𝑎𝑚 = 𝑐𝑚 𝑃𝑑𝑟𝑢𝑚 − 𝑃𝑐𝑜𝑛𝑑 (18)

with cm = 5.21 kg s−1

bar−0,5

and pcond = 0.06 bar.

The saturation temperature Tdrum and‎the‎enthalpy‎increase‎during‎vaporization‎Δhvap

are calculated using the external property functions:

𝑇𝑑𝑟𝑢𝑚 = 𝑇𝑠𝑎𝑡 𝑃𝑑𝑟𝑢𝑚

∆ℎ𝑣𝑎𝑝 = ∆ℎ𝑣𝑎𝑝 𝑃𝑑𝑟𝑢𝑚 (19)

The mass flow rate of steam exiting the evaporator is then given by


57

𝑚 𝑣𝑎𝑝 = 𝑄 𝑣𝑎𝑝

∆ℎ𝑣𝑎𝑝 (20)

Where 𝑄 vap is the heat transferred in the evaporator, calculated as the sum of the heat

transfers in each discretized heat exchanger element:

𝑄 𝑣𝑎𝑝 = 𝑄 𝑠𝑔,𝑠𝑡𝑒𝑒𝑙 −𝑤𝑎𝑡𝑒𝑟 ,𝑖𝑁𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑖=1 (21)

A.1.4 Steam Turbine

The steam turbine calculation is based on an isentropic efficiency calculation. The

specific enthalpy h1 and the specific entropy s1 of the steam entering the turbine can

be calculated with the live steam temperature Tsh, steam, out and the pressure in the

drum Pdrum:

ℎ1 = ℎ 𝑝𝑑𝑟𝑢𝑚 ,𝑇𝑠ℎ ,𝑠𝑡𝑒𝑎𝑚 ,𝑜𝑢𝑡

𝑠1 = 𝑠 𝑃𝑑𝑟𝑢𝑚 ,𝑇𝑠ℎ ,𝑠𝑡𝑒𝑎𝑚 ,𝑜𝑢𝑡 (22)

The steam outlet conditions at an adiabatic reversible expansion are s2s and h2s. While

the specific entropy would remain unchanged s2s = s1, the corresponding specific

enthalpy can be calculated as a function of p2 = pcond = 0.06 bar and s2s:

ℎ2𝑠 = ℎ 𝑃𝑐𝑜𝑛𝑑 , 𝑠2𝑠 (23)

Assuming a constant isentropic‎efficiency‎ηst,‎ the‎real‎specific‎enthalpy‎change‎Δh12

can be deter-mined by solving:

ɳ𝑠𝑡

= ℎ1−ℎ2

ℎ1−ℎ2 = ∆ℎ12

ℎ1−ℎ2 =0.85 (24)

A first-order lag is assumed for the steam turbine power output:

𝜏𝑠𝑡𝑑𝑃 𝑠𝑡𝑑𝑡

= 𝑚 𝑠𝑡𝑒𝑎𝑚 ∆ℎ12 − 𝑃𝑠𝑡 (25)

With‎τst = 10 s as the value for the time constant.


58

The maximum power output of the steam turbine with these settings is Pst, max =

58.818 MW. The total power generated by the plant is the sum of the gas turbine and

the steam turbine power:

Ptot = Pst + Pgt (26)

The maximum power is Ptot, max = 228.818 MW.

A.1.5 Inequality Constraints

Inequality constraints are formulated for unit operations. Maximum temperature

gradients for the drum and for each element of the economizer, evaporator and

superheater are enforced:

𝑑𝑇 𝑑𝑟𝑢𝑚𝑑𝑡

≤ 1.5 𝐾 𝑚𝑖𝑛−1 (27)

𝑑𝑇 𝑒𝑐 ,𝑠𝑡𝑒𝑒𝑙 ,𝑖

𝑑𝑡 ≤ 2.0 𝐾 𝑚𝑖𝑛−1 (28)

𝑑𝑇 𝑠𝑔 ,𝑠𝑡𝑒𝑒𝑙 ,𝑖

𝑑𝑡 ≤ 2.0 𝐾 𝑚𝑖𝑛−1 (29)

𝑑𝑇 𝑠ℎ ,𝑠𝑡𝑒𝑒𝑙 ,𝑖

𝑑𝑡 ≤ 2.0 𝐾 𝑚𝑖𝑛−1 (30)

These values are in practice based on design data. The values in inequalities (27-30)

are chosen arbitrarily.


59


60

A.2 Simulation model:

Appendix B HMI Screens

61

Appendix B

HMI Screens

In this appendix snapshots of the implemented HMI screens is shown.

Main window

Gas turbine


62

Drum

Economizer


63

Super heater

Evaporator


64

Historical trend

Appendix C Quick Guide to KEPServerEX

65

Appendix C

Quick Guide to KEPServerEX

C.1 Introduction

Note: Most of the information collected in this appendix has been collected from (10)

KEPServerEX is a 32-bit windows application that provides a means of bringing data

and information from a wide range of industrial devices and systems into client

applications on the windows PC. With the advent of 32 bit Operating Systems, and

the use of Ethernet to provide communications between devices, there was a need for

quicker and cleaner data transfer between software applications. This is where OPC

saw its birth into the industry.

OPC (OLE for Process and Control) servers provide a standardized method of

allowing multiple industrial applications to share data in a quick and robust manner.

The OPC server provided in this package has been designed to meet the demanding

requirements found in the industrial environment.

This OPC server has been designed as a two-part program. The primary component

provides all of the OPC and DDE connectivity as well as the user interface functions.

The second part is comprised of plug-in communications drivers. This two-part design

allows you to add multiple communications options to your SCADA application

while utilizing a single OPC server product thus reducing your learning curve as your

project grows.

OPC technology reflects the move from closed proprietary solutions to open

architectures that provide more cost-effective solutions based on established

standards.

A Window based client application must be used to view data from the KEPServerEX

application.


66

C.2 Designing a Project

The server must be configured to determine the content of what the server will

provide while it is operating. For a server project, we need to define channels,

devices, optional tag groups, and tags.

Add a new channel

The first step is to determine which communication driver(s) your application

requires. A communication driver in the server is referred to as a channel.

1) To add a new channel to your project you can use either the (Edit/New Channel),

or the Toolbar Add Channel, or the context menu as it is shown here:

2) The channel wizard allows you name the channel and select a communications

driver‎for‎example‎"power‎plant‖.‎Simply‎click‎the‎next‎button‎to‎proceed‎to‎the‎next‎

configuration wizard.

3) The next dialog allows you to select the communications driver that will be applied

to this channel. In our case we select simulator driver.

4) For the simulator driver this scream, display a channel summary page. Then click

the "Finish" button.

The next step is to add a new device to the channel.


67

Add a new device

In most cases a device refers to the identification of a physical node or station on a

communications link. A device can also be viewed solely as a means of framing the

definition of a connection to a specific point of interest in your application.

To add a new device to a channel you need to follow these steps:

1) Select the channel to which you wish to add the device. Once the desired channel

is selected you can use the (Edit/Add Device), the Toolbar Add Device, or the context

menu.

2) The device wizard allows you to name the device which "Nice".

3) The next dialog allows you to select the model that best describes the device that

you are defining, we have chosen 16 bit model from the drop list.

5) For the simulator 16 bit driver the "Next" button will simply display a device

summary page. As shown in the following figure.

With a channel and device added to your project the server is ready to start providing

data to OPC clients.

Now we have to define a set of tags to get data from a device to the client application

using the server.


68

Add a new tag

To add a new tag to a device you need to follow these steps:

1) You must select a device name from the (Channel/Device) tree view within the

server. Once the desired device is selected you can use the (Edit/Add Tag), the

Toolbar Add Tag, or the context menu.

2) After clicking the new tag button you will be presented with the tag properties

dialog. As shown below, the tag properties dialog allows you name the tag, specify a

device specific address, select a data type, and set the access method of the tag. As

shown in the tag dialog above the tag name is "U_GT", the address is "k0000", which

correspond to the address of the device, the description which is optional is "input fuel

percentage", which describes the purpose of this tag, the data type is "Float", client

access is "Read/Write" and DDE scan rate is "100" milliseconds which isn't used for

OPC tags.

Implementation of a Virtual Plant using SCADA/HMI Technology

Documents

Transcript of Implementation of a Virtual Plant using SCADA/HMI Technology