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
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.
I
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.
II
‫المستخلص‬
‫يف ػصشَا ْزا انزي حخزاٌذ فٍّ حكانٍف اإلَخاج ؛ ٌصبح حذود اخطاء َظاو انخحكى وػذو ٌقٍٍُخّ يٍ األيىس انيت‬
‫الميكٍ قبىهلا‪ ،‬ونزنك البذ يٍ انبحذ ػٍ َظاو حماكاة إفخشاضً ري حكهفت يؼقىنت حُاسب انصُاػاث انصغرية‬
‫واملخىسطت ‪ .‬إٌ صُغ انقشاس ٌؼخًذ بشكم أساسً ػهى فهى انؼالقت بني يخغرياحّ املخخهفت وْزا ٌضًٍ احلصىل ػهى‬
‫انُخٍدت املخىقؼت نهقشاس‪ ،‬وميكُُا انقىل بؤٌ ػًهٍت احملاكاة اإلفخشاضٍت ملُشؤة يا متثم األسضٍت انيت حقىد إيل فهى أفضم‬
‫وواقؼً نهًُشؤة وبانخايل متثم َقطت اإلَطالق ألي حصًٍى او إخخباس خذٌذ وحضغ اٌضا اسخشاحٍدٍاث انخطىس‬
‫املسخقبهً ‪.‬‬
‫َظى احملاكاة اإلفُشاضٍت انسائذة حانٍا ػانٍت انخكانٍف سىاءً كاَج انخكانٍف األونٍت أو خهىد حطىٌش ْزِ األَظًت ‪،‬‬
‫األيش انزي جيؼهها حكاد حكىٌ قصشا ػهى جماالث انصُاػاث انُىوٌت وانفضائبت ‪.‬‬
‫َظاو حماكاة ا فخشاضً باسخخذاو انخكُىنىخٍا‬ ‫اهلذف يٍ ْزا املششوع ْى انقٍاو بىضغ طشٌقت نخصًٍى وحُفٍز‬
‫املىخىدة يف جمال أَظًت انخحكى اإلششايف واحلصىل ػهى انبٍاَاث )‪ ، (SCADA‬مت اسخخذاو بشَايح حماكاة‬
‫يخؼذد األغشاض يٍ أخم منزخت و حماكاة املُشؤة ‪ ،‬و كزنك اسخخذيج بشجمٍاث انشبط بني االَساٌ و اَنت‬
‫)‪ (HMI‬بغشض حقهٍذ واخهاث َظاو انخحكى ‪ ،‬ػًهٍت انشبط بني ْزٌٍ انربَاجمني متج باسخخذاو حكُىنىخٍا‬
‫ال‪. OPC‬‬
‫انطشٌقت املخبؼت َخدج ػٍ َظاو اقخصادي ‪ ،‬فؼال و يشٌ ‪ .‬األيش انزي ميكٍ يٍ اسخخذاو َظى احملاكاة اإلفخشاضٍت‬
‫نهؼذٌذ يٍ املُشآث انصغرية و املخىسطت‪.‬‬
‫‪III‬‬
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
IV
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
V
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
VI
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
VII
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
VIII
Chapter 1 Introduction
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
1
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.
2
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.
3
Chapter 2 Literature Review
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
4
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.
5
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,
6
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
7
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.
8
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
9
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).
10
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.
11
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
12
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.
13
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.
14
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.
15
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.:
16
•‎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.
17
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.
18
•‎ 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
19
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-
20
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]
21
Chapter 3 Description of design and implementation methodology
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
22
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.
Virtual Plant Environment
HMI
User
OPC Server
Simulated Process
Model
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.
23
 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.
24
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.
25
Virtual Plant Environment
InTouch
Login
g
HMI
Tag Name Dictionary
Disc
DDE
User
OPC Server
KEPServerEX
OPC Toolbox
Simulated Process Model

Simulink
Developer
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.
26
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.
27
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 Tsteam_ss: Temperature of the steam
leaving the turbine leaving the superheater
Tgas_in: Temperature of flue gases Tgas_ss: Temperature of flue gases
entering the superheater leaving the superheater
𝑚steam: mass flow rate of entering
the superheater
Pdrum: Pressure in the drum
Tdrum: Temperature of the drum.
Steam Turbine 𝑚steam: mass flow rate of entering Psteam: Output power of the steam
the superheater turbine
Tsteam_ss: Temperature of the steam
28
leaving the superheater
Drum Tec_water: Temperature of water 𝑚steam: mass flow rate of entering the
leaving the economizer superheater
𝑚vap: mass flow rate of steam Pdrum: Pressure in the drum
evaporated in the evaporator Tdrum: Temperature in the drum.
∆ℎvap: heat of evaporation of water in
the drum
Evaporator 𝑚gas: mass flow rate of flue gases Tgas_evap: Temperature of flue gases
leaving the turbine leaving the evaporator
Tgas_ss: Temperature of flue gases 𝑚vap: mass flow rate of steam
leaving the superheater evaporated in the evaporator
Tdrum: Temperature in the drum.
∆ℎvap: heat of evaporation of
water in the drum
Economizer 𝑚gas: mass flow rate of flue gases Texhaust_gas: Temperature of flue gases
leaving the turbine leaving the system
Tgas_evap: Temperature of flue Tec_water : Temperature of the water
gases leaving the evaporator heated in the economizer..
𝑚feedwater: mass flow rate of
feedwater is assumed to equal
𝑚steam
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.
29
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
30
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
31
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.
32
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 write only the
control method 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
The device name nice
Device id 1
The device model 16 bit device
Table 3.4: Device settings
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
33
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.
34
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.
35
 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.
36
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.
37
Process
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 -
38
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.
39
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.
Disc
WindowViewr Run-Time Environment Historical Log Files
IDX
Historical
Logger
LGH
Plant Total
Plant Fuel
Output
Utilization
Power
Historical
Trend
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,
40
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.
Script:
MWhr = MWhr+((0.1 / 3600) * P_TOTAL);
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.
Power
Time
100
mS
Figure 3.10: Numerical integration of power over time by application script
41
42
Chapter4 Testing and Results
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].
43
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)
44
(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.
45
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
46
47
Chaprer 5 Conclusion and Future Work
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.
48
Chaprer 5 Conclusion and Future Work
 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 LOG
Search
Engine LOG
Dynamic
Simulation
LOG
Tieback delay
model
Figure 5.1: Illustration of historical tieback method
49
References
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.
50
References
[13] Modern SCADA Systems for Oil Pipelines. Trung, Duong. s.l. : IEEE. Paper
No. PCIC-95-32.
51
Appendix A Modeling and Simulating the Process
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.
52
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

𝑚𝑔𝑎𝑠 = (1)
260.058ugt + 173.37 if 0.5 < ugt ≤ 1
517𝑢𝑔𝑡 + 29
𝑇𝑔𝑡 ,𝑜𝑢𝑡 = (2)
550
The power of the gas turbine Pgt is given by
53
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 Component Heat transfer coefficient

A mass msteel U [W m−2 K−1]
Economizer 20,000 60,000 kg Gas-Steel 30
m2 Steel-Water 500
Evaporator 20,000 90,000 kg Gas-Steel 40
m2 Steel-Water 500
Superheater 30,000 90,000 kg Gas-Steel 20
m2 Steel-Steam 500
54
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.
55
 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
56
𝑄 𝑣𝑎𝑝
𝑚𝑣𝑎𝑝 = ∆ℎ 𝑣𝑎𝑝
(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 = ℎ 𝑝𝑑𝑟𝑢𝑚 , 𝑇𝑠ℎ,𝑠𝑡𝑒𝑎𝑚 ,𝑜𝑢𝑡
(22)
𝑠1 = 𝑠 𝑃𝑑𝑟𝑢𝑚 , 𝑇𝑠ℎ,𝑠𝑡𝑒𝑎𝑚 ,𝑜𝑢𝑡
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 ∆ℎ 12
ɳ𝑠𝑡 = ℎ 1−ℎ 2
= ℎ 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.
57
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.
58
59
A.2 Simulation model:
60
Appendix B HMI Screens
Appendix B
HMI Screens
In this appendix snapshots of the implemented HMI screens is shown.
 Main window
 Gas turbine
61
 Drum
 Economizer
62
 Super heater
 Evaporator
63
 Historical trend
64
Appendix C Quick Guide to KEPServerEX
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.
65
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.
66
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.
67
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.
68

Implementation of A Virtual Plant Using SCADA/HMI Technology

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

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

‫نهؼذٌذ يٍ املُشآث انصغرية و املخىسطت‪.‬‬

‎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.8: TAGS TYPES IN INTOUCH 38

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

‎FIGURE 5.1: ILLUSTRATION OF HISTORICAL TIEBACK METHOD 49

TABLE 3.1: SUBSYSTEMS INPUTS/OUTPUTS 29

SCADA Supervisory Control and Data Acquisition

ERP Enterprise Recourse Planning

MES Manufacturing Execution System

1.2 Statement of the problem

1.3 Project Objectives

1.4 Methodology and Tools

1.5 Thesis Layout

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

2.1 Supervisory Control and Data Acquisition (SCADA)

2.1.1 Historical Background

2.1.2 SCADA: Concept

Figure 2.1: SCADA Layout

Figure 2.2: A Typical SCADA System

2.1.4 SCADA: Software Archeticture

‎0Figure 2.3:Generic SCADA Software Architecture

2.1.5 SCADA: Software Functionality

2.1.5 SCADA: Communication

2.1.5.1 Communication architectures

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

Multi-point architecture (Multiple stations)

Figure 2.5: Multi-point Architecture

Relay station architecture

Figure 2.6: Store and forward

Figure 2.7: Talk through repeaters

2.1.5.2 Communication philosophies

2.2 OLE for Process Control (OPC)

Figure 2.8: OPC Client/Server Relationship

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

2.2.2 OPC standards

2.2.2.1 OPC DataAccess

Figure 2.9: Group/Item Relationship

2.2.2.2 OPC Alarm and Event Handling

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

2.2.2.3 OPC Historical Data Access

2.4 Process Modelling and Simulation

2.4.1 Systems and Experiments

2.4.2 The Model Concept

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

2.4.4 Kinds of Mathematical Models

Dynamic vs. Static Models

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

Continuous-Time vs. Discrete-Time Dynamic Models