Documente Academic
Documente Profesional
Documente Cultură
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
VI
List of Tables
VII
Abbreviations
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‘sperformance.
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
Chapter 1 Introduction
implementations where the dynamic model had to be written from scratch and the
control system and displays had to be emulated by programmers.
2
Chapter 1 Introduction
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.
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‘sinstructionstothevalvesandmotorsintheprocess.
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
Chapter 2 Literature Review
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 toopenandcloserelays.That―something,‖whichlater 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]
5
Chapter 2 Literature Review
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 ishowfar‗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).
On a more complex SCADA system there are essentially five levels or hierarchies:
•Fieldlevelinstrumentationandcontroldevices
•MarshallingterminalsandRTUs
•Communicationssystem
•Themasterstation(s)
•Thecommercial 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
Chapter 2 Literature Review
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]
7
Chapter 2 Literature Review
8
Chapter 2 Literature Review
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 decomposetheprocessin―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:
•theparameterstobetrendedinaspecificchart 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
•historicaltrendingispossiblefor any archived parameter
•zoomingandscrollingfunctionsareprovided
•parametervaluesatthecursorpositioncanbe 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
Chapter 2 Literature Review
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
Chapter 2 Literature Review
11
Chapter 2 Literature Review
12
Chapter 2 Literature Review
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
Chapter 2 Literature Review
2.2.1 Overview
AnOPC―OLE(ObjectLinkingandEmbedding)forProcessControl‖isastandard
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).
14
Chapter 2 Literature Review
15
Chapter 2 Literature Review
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:
•SimpleTrenddataservers.Theseserversprovidedlittleelsethensimplerawdata
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]
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
Chapter 2 Literature Review
•Theinputsofasystemarevariablesoftheenvironmentthatinfluencethebehavior
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.
17
Chapter 2 Literature Review
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:
•Experimentsaretooexpensive,toodangerous,orthesystemtobeinvestigateddoes
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
Chapter 2 Literature Review
19
Chapter 2 Literature Review
20
Chapter 2 Literature Review
21
Chapter 3 Description of design and implementation methodology
Chapter 3
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.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.
HMI
User
OPC Server
Simulated Process
Model
Developer
23
Chapter 3 Description of design and implementation methodology
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.
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].
24
Chapter 3 Description of design and implementation methodology
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.
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.
25
Chapter 3 Description of design and implementation methodology
InTouch
Login
g
HMI
Tag Name Dictionary
Disc
DDE
User
OPC Server
KEPServerEX
OPC Toolbox
Developer
26
Chapter 3 Description of design and implementation methodology
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
Chapter 3 Description of design and implementation methodology
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.
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
Pdrum: Pressure in the drum
Tsteam_ss: Temperature of the steam
28
Chapter 3 Description of design and implementation methodology
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
Pdrum: Pressure in the drum
29
Chapter 3 Description of design and implementation methodology
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.
30
Chapter 3 Description of design and implementation methodology
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.
31
Chapter 3 Description of design and implementation methodology
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.
32
Chapter 3 Description of design and implementation methodology
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.
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
Device id 1
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
33
Chapter 3 Description of design and implementation methodology
34
Chapter 3 Description of design and implementation methodology
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.
35
Chapter 3 Description of design and implementation methodology
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
Chapter 3 Description of design and implementation methodology
37
Chapter 3 Description of design and implementation methodology
Process
38
Chapter 3 Description of design and implementation methodology
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.
39
Chapter 3 Description of design and implementation methodology
Disc
IDX
Historical
Logger
LGH
Plant Total
Plant Fuel
Output
Utilization
Power
Historical
Trend
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.
40
Chapter 3 Description of design and implementation methodology
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
41
Chapter 3 Description of design and implementation methodology
42
Chapter4 Testing and Results
Chapter 4
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.
43
Chapter4 Testing and Results
(a)
44
Chapter4 Testing and Results
(b)
Figure 4.1: Linking Simulink (a) to OPC server (b) showing identical results
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‘sTagnamedictionary
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
Chapter4 Testing and Results
(a)
(b)
Figure 4.2: Screen snapshot that shows: (a) Simulink scope data (b) HMI historical Trends
46
Chapter4 Testing and Results
47
Chaprer 5 Conclusion and Future Work
Chapter 5
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 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.
Historiacal Data
Virtual Plant
Environment
HMI LOG
Search
Engine LOG
Dynamic
Simulation
LOG
Tieback delay
model
49
References
References
[2] Bailey, David and Wright, Edwin. Practical SCADA for Industry. Oxford :
Newnes, 2003.
[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.
[11] InTouch® HMI Data Management Guide. s.l. : Invensys Systems Inc., 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
52
Appendix A Modeling and Simulating the Process
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:
53
Appendix A Modeling and Simulating the Process
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.
54
Appendix A Modeling and Simulating the Process
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)
𝑒𝑙𝑒𝑚𝑒𝑛𝑡
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)
55
Appendix A Modeling and Simulating the Process
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:
𝑄 𝑎𝑝𝑝𝑟𝑜𝑎𝑐 ℎ
𝑚𝑎𝑝𝑝𝑟𝑜𝑎𝑐 ℎ = ∆ℎ 𝑣𝑎𝑝
(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 andtheenthalpyincreaseduringvaporizationΔhvap
are calculated using the external property functions:
𝑇𝑑𝑟𝑢𝑚 = 𝑇 𝑠𝑎𝑡 𝑃𝑑𝑟𝑢𝑚
(19)
∆ℎ𝑣𝑎𝑝 = ∆ℎ𝑣𝑎𝑝 𝑃𝑑𝑟𝑢𝑚
The mass flow rate of steam exiting the evaporator is then given by
56
Appendix A Modeling and Simulating the Process
𝑄 𝑣𝑎𝑝
𝑚𝑣𝑎𝑝 = ∆ℎ 𝑣𝑎𝑝
(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)
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:
ℎ 1 −ℎ 2 ∆ℎ 12
ɳ𝑠𝑡 = ℎ 1−ℎ 2
= ℎ 1 −ℎ 2
=0.85 (24)
57
Appendix A Modeling and Simulating the Process
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)
𝑑𝑇 𝑑𝑟𝑢𝑚
𝑑𝑡
≤ 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
Appendix A Modeling and Simulating the Process
59
Appendix A Modeling and Simulating the Process
60
Appendix B HMI Screens
Appendix B
HMI Screens
Main window
Gas turbine
61
Appendix B HMI Screens
Drum
Economizer
62
Appendix B HMI Screens
Super heater
Evaporator
63
Appendix B HMI Screens
Historical trend
64
Appendix C Quick Guide to KEPServerEX
Appendix C
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
Appendix C Quick Guide to KEPServerEX
66
Appendix C Quick Guide to KEPServerEX
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
Appendix C Quick Guide to KEPServerEX
68