Modelling and Simulation of A Gas Turbine: Henrik Klang Andreas Lindholm

Examensarbete
LITH-ITN-ED-EX--05/009--SE
Modelling and simulation of a gas

turbine
Henrik Klang
Andreas Lindholm
2005-04-22
Department of Science and Technology Institutionen för teknik och naturvetenskap

Linköpings Universitet Linköpings Universitet
SE-601 74 Norrköping, Sweden 601 74 Norrköping
LITH-ITN-ED-EX--05/009--SE
Modelling and simulation of a gas

turbine
Examensarbete utfört i Elektronikdesign
vid Linköpings Tekniska Högskola, Campus
Norrköping
Henrik Klang
Andreas Lindholm
Handledare Tomas Strömberg

Examinator Måns Östring
Norrköping 2005-04-22
Datum
Avdelning, Institution Date
Division, Department
Institutionen för teknik och naturvetenskap 2005-04-22
Department of Science and Technology
Språk Rapporttyp ISBN

Language Report category _____________________________________________________
Svenska/Swedish Examensarbete ISRN LITH-ITN-ED-EX--05/009--SE
x Engelska/English B-uppsats _________________________________________________________________
C-uppsats Serietitel och serienummer ISSN
x D-uppsats Title of series, numbering ___________________________________
_ ________________
_ ________________
URL för elektronisk version

http://www.ep.liu.se/exjobb/itn/2005/ed/009/
Titel
Title Modelling and simulation of a gas turbine
Författare
Author Henrik Klang, Andreas Lindholm
Sammanfattning
Abstract In this thesis, a gas turbine simulator for the Siemens GT10C was developed and implemented.
It concerns everything from the theory behind the simulator; both the hardware and software involved,
to how the actual simulator was built using these tools. The theory concerns itself with basic automatic
control concepts, as well as basic turbine theory.
The simulator setup is being discussed concerning both technical and economic issues. A robust
hardware solution is then selected, using the basic requirements, which the simulator then is built
around.
The tools used are the Siemens SIMATIC automatic control system and the Siemens SIMIT real-time
simulator using a SIMBA Pro PCI card to interface with the PLC:s in the SIMATIC system. Matlab are
also used to a lesser extent to build the simulator behavior in SIMIT.
In the end, a fully featured simulator is presented that can be used for various purposes such as training
operators, trying out new concepts and testing the automatic control system used to control the turbine.
Further development that could be done, by other engineers, in the future, is also discussed.
Nyckelord
Keyword Automatic control, fieldbus, gas turbine, modelling, S7, Siemens, SIMATIC, SIMBA, SIMIT, PLC,
PROFIBUS, simulation
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –

under en längre tid från publiceringsdatum under förutsättning att inga extra-
ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida http://www.ep.liu.se/
Copyright
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page: http://www.ep.liu.se/
© Henrik Klang, Andreas Lindholm

Preface i
Preface
This thesis is a result of about 20 weeks of analysis and implementation at
Siemens Industrial Turbomachinery AB, Finspång, Sweden.
It is a compulsory part of the education for the authors to receive their
Master of Science degree in Electronics Design Engineering from the Department
of Technology and Natural Sciences (ITN) at Linköping Institute of Technology.
The work was carried out in between June and November of 2004. The exam-
iner at Linköping Institute of Technology was Måns Östring and the instructor
at Siemens Industrial Turbomachinery AB, Thomas Strömberg.
The thesis was done in co-operation with another thesis worker, Daniel Wi-
gren, which also is a student at Linköping Institute of Technology studying to
receive a degree as a Master of Science in Applied Physics and Electrical Engi-
neering.
Henrik Klang and Andreas Lindholm.
Stockholm and Finspång, February 2005.

ii
Thank you!
To everyone who deserves it.
Mandatory quotes from (in)famous persons iii
Mandatory quotes from (in)famous persons

“ ‘Students?’ barked the Archchancellor. ‘Yes, Master. You know?
They’re the thinner ones with the pale faces? Because we’re a
∗university∗? They come with the whole thing, like rats’ ” - Terry
Pratchett (author, Moving Pictures)
“Sometimes a scream is better than a thesis.” - Ralph Waldo Emer-

son (US essayist & poet, Journals)
iv
Abstract
In this thesis, a gas turbine simulator for the Siemens GT10C was developed
and implemented.
It concerns everything from the theory behind the simulator; both the hard-
ware and software involved, to how the actual simulator was built using these
tools. The theory concerns itself with basic automatic control concepts, as well
as basic turbine theory.
The simulator setup is being discussed concerning both technical and eco-
nomic issues. A robust hardware solution is then selected, using the basic re-
quirements, which the simulator then is built around.
The tools used are the Siemens SIMATIC automatic control system and the
Siemens SIMIT real-time simulator using a SIMBA Pro PCI card to interface
with the PLC:s in the SIMATIC system. Matlab are also used to a lesser extent
to build the simulator behavior in SIMIT.
In the end, a fully featured simulator is presented that can be used for various
purposes such as training operators, trying out new concepts and testing the
automatic control system used to control the turbine.
Further development that could be done, by other engineers, in the future,
is also discussed.
Keywords: Automatic control, fieldbus, gas turbine, modelling, S7, Siemens,

SIMATIC, SIMBA, SIMIT, PLC, PROFIBUS, simulation.
CONTENTS v
Contents
Abstract iv
1 INTRODUCTION 1
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Questions at hand . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 History of the Finspång development site . . . . . . . . . . . . . 2
1.6 The structure of this thesis . . . . . . . . . . . . . . . . . . . . . 2
2 THEORY 4
2.1 Overview of fieldbus technology . . . . . . . . . . . . . . . . . . . 4
2.2 PROFIBUS° R
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 PROFIBUS-DP° R
. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 The Siemens SIMATIC totally integrated automation system . . 7
2.6 SIMATIC hardware . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7 Engineering and operator stations . . . . . . . . . . . . . . . . . 7
2.7.1 S7 PLC’s . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.7.2 DP-slaves explained . . . . . . . . . . . . . . . . . . . . . 9
2.8 SIMATIC software . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.8.1 SIMATIC manager . . . . . . . . . . . . . . . . . . . . . . 10
2.8.2 Hardware config . . . . . . . . . . . . . . . . . . . . . . . 11
2.8.3 SFC editor . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8.4 CFC editor . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.5 NetPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8.6 Fail-safe versus non fail-safe . . . . . . . . . . . . . . . . . 12
2.8.7 WinCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 The Siemens SIMIT simulation system . . . . . . . . . . . . . . . 13
2.9.1 SIMBA Pro . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9.2 Using SIMIT . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.10 The Siemens GT10C gas turbine . . . . . . . . . . . . . . . . . . 15
2.10.1 Compressor . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.10.2 Combustion chamber . . . . . . . . . . . . . . . . . . . . . 17
2.10.3 Power turbine . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.11 Turbine regulators . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.11.1 STC - starting control . . . . . . . . . . . . . . . . . . . . 19
2.11.2 NGGL - gas generator speed limiter . . . . . . . . . . . . 19
2.11.3 SC - speed controller . . . . . . . . . . . . . . . . . . . . . 20
2.11.4 T7L - exhaust average temperature limiter . . . . . . . . 20
2.11.5 T7Li - exhaust inner temperature limiter . . . . . . . . . 20
2.11.6 MPC - maximum servo position control . . . . . . . . . . 20
2.11.7 GAC - gas generator acceleration control . . . . . . . . . 20
2.11.8 GDC - gas generator deceleration control . . . . . . . . . 21
2.11.9 PAC - power turbine acceleration control . . . . . . . . . 21
2.11.10 LLD - loss of load detection . . . . . . . . . . . . . . . . . 21
2.12 Automated start of turbine . . . . . . . . . . . . . . . . . . . . . 21
2.12.1 Unit sequence . . . . . . . . . . . . . . . . . . . . . . . . . 21
vi CONTENTS
2.12.2 Gas fuel sequence . . . . . . . . . . . . . . . . . . . . . . . 21

2.12.3 Turbine sequence . . . . . . . . . . . . . . . . . . . . . . . 23
2.12.4 A start of the turbine using the sequences . . . . . . . . . 23
2.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 DECIDING THE SIMULATOR SETUP 25

3.1 Different solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Solution I - PLC—PLC . . . . . . . . . . . . . . . . . . . 26
3.1.2 Solution II - Simulator and control system in same PLC . 27
3.1.3 Solution III - PLC—PC/C/C++ (Java) . . . . . . . . . . 27
3.1.4 Solution IV - PLC—PC/Simulink . . . . . . . . . . . . . 28
3.1.5 Solution V - PLC–SIMIT (chosen) . . . . . . . . . . . . . 29
3.1.6 Conclussions . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 IMPLEMENTING THE SIMULATOR AND THE MODEL 32

4.1 Setting up the simulator . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Closed and open loop control . . . . . . . . . . . . . . . . . . . . 32
4.3 Building HMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 The development cycle . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 A simulation diagram example (calculating heat flow) . . . . . . 35
4.5.1 Using performance data . . . . . . . . . . . . . . . . . . . 35
4.5.2 Heat flow versus speed, temperature and pressure . . . . . 38
4.5.3 The pilot flame . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5.4 Necessary adjustments . . . . . . . . . . . . . . . . . . . . 38
4.5.5 A run with the model . . . . . . . . . . . . . . . . . . . . 38
5 RESULT 41
5.1 Conclusions and discussion . . . . . . . . . . . . . . . . . . . . . 41
5.2 Future development . . . . . . . . . . . . . . . . . . . . . . . . . 42
References 43
LIST OF FIGURES vii
List of Figures
2.1 Old fieldbus network. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Modern fieldbus network. . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Two Siemens SIMATIC S7 PLC boxes (back) connected to DP-
slaves (front). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Basic configuration with a DP-rack in the hardware config editor 11
2.5 Two typical CFC-blocks, normal (left) vs. fail-safe (right). . . . . 12
2.6 SIMIT and SIMBA Pro interaction scheme (OS and ES comput-
ers connected to the S7 PLC are not included). . . . . . . . . . . 14
2.7 SIMBA Pro list of configured DP-slaves. . . . . . . . . . . . . . . 14
2.8 Example of a SIMIT diagram/modell. . . . . . . . . . . . . . . . 15
2.9 The GT10C gas turbine is a turbine with two rotors, the com-
pressor rotor and the power turbine rotor. This type is known
as a double shaft turbine. The three main parts of the turbine is
enclosed in red. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.10 The compressor valves locations of the turbine. . . . . . . . . . . 17
3.11 Solution I, PLC to PLC communication (simplified schematic). . 27
3.12 Solution III & IV, PLC to PC (C/C++/SimuLink) communica-
tion (simplified schematic). . . . . . . . . . . . . . . . . . . . . . 29
3.13 Final hardware setup with the turbine PLC’s containing the con-
trol program and the PC containing the turbine simulation pro-
gram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.14 The HMI of a turbine system (operator screen). . . . . . . . . . . 33
4.15 Grouping of diagram and operating screens in SIMIT. The dif-
ferent alphanumeric codes are an internal Siemens scheme for
naming different systems in the turbine. . . . . . . . . . . . . . . 34
4.16 Simple development process flowchart of the simulator model. . . 36
4.17 Data from performance tests used when developing the model. . 37
4.18 The relation between the curve taken from SCADA Pro (blue)
and the polygon curve done with Matlab (red). . . . . . . . . . . 37
4.19 The SIMIT model to calculate the heat flow value. . . . . . . . . 39
viii LIST OF TABLES
List of Tables
2.1 Comparison between PROFIBUS and older fieldbus standards . . 5
2.2 Speed versus pressure ratio in the compressor. . . . . . . . . . . . 17
2.3 Valve characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 The unit sequence which starts up turbine. . . . . . . . . . . . . 22
2.5 Gas fuel sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Turbine sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Quick recap of investment costs for each solution. Notes: 1 A
more powerful PLC might be needed. 2 If implemented. . . . . . . 30
ABBREVIATIONS ix
Abbreviations
AI Analogue In
API Application Programming Interface
AO Analogue Out
CC Control Center
CFC Continuous Function Chart
CP Communication Peripheral
CPU Central Processing Unit
DI Digital In
DIP Dual-Inline Package
DO Digital Out
DOS Disk Operating System
DP Decentralized Peripheral
ES Engineering Station
FAT Factory Acceptance Test
GDC Gas generator Deceleration Control
GUI Graphical User Interface
HMI Human Machine Interface
I[/]O Input/Output
I 2C Inter-Integrated Circuit
IGV Inlet Guide Vane
IPX Internetwork Packet Exchange
MAC Media Access Control
MPI Multipoint Interface
NIC Network Interface Card
OLE Object Linking and Embedding
OPC OLE for Process Control
OS Operator Station
OSI Open System Interconnection [Reference Model]
PCI Peripheral Component Interconnect
PCS Process Control System
PID Proportional Integration Derivation
PLC Programmable Logic Controller
PROFIBUS PROcess FIeld BUS
PS[U] Power SUpply
PT Power Turbine
RAM Random Access Memory
SCADA Supervisory Control and Data Acquisition
SCL Structured Control Language
SFC Sequential Function Chart
TCP/IP Transmission Control Protocol/Internet Protocol
UR2 Universal Rack Type 2
1 INTRODUCTION 1
1 INTRODUCTION
1.1 Purpose
The primary purpose of this thesis is to develop a simulator and model for
a specific gas turbine, the GT10C; which uses the Siemens SIMATIC system
(“SIMATIC”, also referred to as “S7” where 7 is the latest version of SIMATIC).
When this is done the model of the gas turbine will be implemented in the system
which has been devised.
Secondary purpose are to include more additions to the simulator, such as
simulating the next coming stages in the turbine system; compressors, and other
loads. More wanted additions is to be able to simulate other turbine models in
the same family.
The first goal of the thesis is to analyze what kind of system that would be
needed to build and implement the simulator itself, both hard- and soft wise.
When this is done, the actual simulator will be implemented in the developed
system, and finally, at the end, tested against the actual turbine automation
and control system located in multiple S7 PLC boxes.
This thesis is being carried out at Siemens Industrial Turbomachinery AB
(“Siemens”) located in Finspång, Sweden which is a part of the Siemens group.
1.2 Background
Siemens Industrial Turbomachinery AB is about to adopt the S7 system, thus
replacing the currently used one developed by ABB.
The current project at hand (as of June 2004) is to install a GT10C gas
turbine in Eischleben, Germany. This is the first project, in Finspång, to use
the S7 system from Siemens, thus the development of a simulator would be
helpful in the entire development cycle of a turbine and its systems.
The simulator will be used for system testing, training new operators and
simulating new additions to the automatic control system, before the system
is tested in an actual turbine on site. This will help reduce, both development
cost, and time to market, for new additions to the system. Moreover, it will
shorten the time spent training operators for a specific turbine thus increasing
total profit per installed turbine and project.
1.3 Questions at hand

A number of questions were formulated to use during the entire thesis process.
Each one of these questions will be answered in this thesis report.
Primary,
• What kind of system should be used for the simulator?
• How should the communication work in between the simulator and the
PLC. Is there any ready-made solutions to use?
• What system is feasible to use concerning cost, training, and implemen-

tation time?
• In which way should the human machine interface of the simulator be

implemented and designed to be as easy as possible?
2
Secondary,
• How should other turbine models be implemented in the simulator and

can it be done in a reasonable time frame?
1.4 Limitations
The initial limitations will be to devise a simulator for only one turbine, the
GT10C. Although extending the simulator for other turbine types such as the
GTX100 would be favorable.
At first the model of the turbine shall be static, that is, no dynamic signals
shall be modeled. Static signals in this report refers to such ones that does not
use any feedback when calculating the output signals of the system.
If, and when, the static modeling is done, a half dynamic model should be
developed. In this report a half dynamic model is a model where analogue and
digital signals can be triggered by other signals, but not as a closed loop, such
as a PID (for further discussion of these concepts please refer to Section 4).
Furthermore, an external unit (load) of the turbine, shall be modeled if there
is any time.
1.5 History of the Finspång development site

The Finspång site has been developing and producing power generation equip-
ment approximately 100 years. In 1913 Svenska Turbinfabriksaktiebolaget Ljung-
ström (Swedish turbine factory Ljungström) was formed (known as STAL). In
the 1950’s they merge with DeLaval and formes STAL-Laval.
In the middle of the 1980’s ASEA buys the entire company which later
becomes ABB STAL AB.
In 1999 ABB Alstom Power Sweden AB is formed and in the same year the
gas turbine GT10C is developed. This is the turbine that the simulator in this
thesis simulates.
Finally in 2003 Siemens buys the company and renames it Demag DeLaval
Industrial Turbomachinery AB which in October of 2004 became Siemens In-
dustrial Turbomachinery AB.
1.6 The structure of this thesis

In the first chapter, THEORY, an explanation of automation control concepts
and turbine theory will be introduced. This is the perquisites to understand
the reasoning behind, both the model, and how the simulation system was
developed. This chapter also explains the programs used and how they work
together and individually.
In the chapter DECIDING THE SIMULATOR SETUP the entire sim-
ulator hardware will be explained. Why and how the hardware and software
was chosen and how the system was put together. Both technical and economic
issues are taken into consideration here.
In IMPLEMENTING THE SIMULATOR AND THE MODEL logic
behind the actual turbine model will be explained in detail. Also the HMI will
be shortly discussed and some other important aspects concerning the simulator
implementation itself.
1.6 The structure of this thesis 3
Last, the chapter RESULT discusses the results, and what could have been
done differently. Also future improvement that would be possible is discussed
here.
4
2 THEORY
To be able to understand the next coming chapters some explanations of the
terms and concepts, in this thesis, will be discussed below. A simple overview
of the programs used will also be presented to give the reader a more in depth
view of the problems the authors faced and measures taken to solve these.
This chapter also explains, on a very low level, how a turbine works, and
especially the turbine which the simulator in this thesis is developed for.
2.1 Overview of fieldbus technology

Fieldbus[1][2] technology is a major step in the process control industry. In
older systems, signals sent used to be unidirectional and traditionally 4 − 20mA
analogue.
Fieldbus technology on the other hand is a replacement for this type of
older systems and extends the entire process control concept from the bottom-
up approach to a more sophisticated top-down thinking. The modern fieldbus of
today acts as an entire network; much like the Internet. It connects everything
from PLC’s, engineering and operator stations to low level field devices on the
factory floor such as actuators, sensors, transducers and drives.
The fieldbus networks makes use of modern communication standards such
as TCP/IP, IPX and Ethernet. These networks interconnect over large areas
where the operator can be in Australia and the process which the operator
controls could be located somewhere in Europe (in theory, but not very likely
used in practise).
This in turn opens for entirely new possibilities such as remotely developing
and upgrading systems, monitoring factory processes and supporting on site op-
erators within the accessible process network. Optimizing processes and finding
possible bottle necks more rapidly are other benefits.
Down sides to the modern fieldbus networks could be speed and congestion
problems due to the large amount of traffic being sent on the same network
(cable) and over other “unknown” networks such as Internet cables which the
engineer does not have control over. Older[2] technologies relied on several
hundred of cables (Figure 2.1), one for each signal, up to the PLC’s and op-
erator/engineering stations, while modern fieldbus networks interconnects the
process objects with each other at central access points. The objects are often
connected in a serial fashion thus creating bottle necks along the way if much
traffic and information exchange is needed between the process objects and the
process control itself. Although this can be helped with new technologies such
as fiber cables sending information using light instead of electrical signals or
installing a second cable so that the objects are connected in parallel; though
this would require another PLC box.
For an easy overlook of the difference between older network properties and
modern such as fieldbus, see Table 2.1.
Going more extensively into the positive properties of fieldbus technology
some are,
• Design and engineering - Building the networks around well defined

and known standards and concepts both reduce design and planing time,
as well as helps minimize the documentation needed.
2.2 PROFIBUS°
R
5
older standards profibus

Signals Analogue Digital (packet based)
Unidirectional Bidirectional
Cables One for each signal. Multiple signals can
share a cable.
Networking Multiplexing of signals Signal information can be
needed at a central hub. easily relayed to multiple
end points both local
and global.
Diagnosis Basic diagnosis More extensive information
information. can be provided (“intelligent
slaves”).
Commissioning More expensive due to Less cables, easier layout
complex networks and of the network.
more cables.
Table 2.1: Comparison between PROFIBUS and older fieldbus standards
• Installation and commissioning - Since the fieldbus I/O’s can be more

diverse with less cables required in the process, both cost and time is re-
duced during commissioning and installation of the network and its sur-
rounding process objects, PLC’s and higher monitoring tools.
• Easier operation and maintenance - The data being transferred on
the network can be more diverse than traditional analogue process net-
works since the standards is built around packet sending services similar
to TCP/IP. This means that, not only digital and analogue signal infor-
mation can be sent, but also extensive diagnostic information from each
process object located in the system process. The information can also be
easily sent to several endpoints in the factory network as well as larger net-
works such as the Internet. This makes it easier co-operating and finding
the actual errors or solutions to the problems at hand.
There are several fieldbus standards such as PROFIBUS, INTERBUS, MPI
and Industrial Ethernet. Some are proprietary while others are open. Common
for all is that they are used by industrial applications and are certified to work
under the very different environment of a plant versus an office. The difference
are mostly in how the software protocol is implemented, as well as physical
properties of the cables and signal levels.
2.2 PROFIBUS°
R
PROFIBUS[3] specifies everything from the medias electrical properties (the

cable) to the protocol specifications over the cables.
PROFIBUS is a simple two-wire buss (much like Phillips I 2 C), built to be
robust in rugged environments, using a minimal and easy to implement protocol,
with a minimal overhead. Thus reducing down time and need for maintenance.
PROFIBUS is an open standard1 and was developed as a research project, in-
volving several major corporations and research institutes, between 1987−1990.
1 IEC 61158-1 through IEC 61158-6
6
Location A
PLC
Location B Location C
Figure 2.1: Old fieldbus network.
Location A
PLC
Fieldbus Cable
I/O device I/O device
Location B Location C
Figure 2.2: Modern fieldbus network.
PROFIBUS is the leader of fieldbus communication with over 20 per cent of the
world market. Approximately 500.000 plants and factories use PROFIBUS,
with over 5 million nodes2 installed.
2.3 PROFIBUS-DP°
R
PROFIBUS-DP[3] is a extension of the PROFIBUS standard which is designed

for fast data exchange at field level. The distribution is cyclic. It works much
like “token ring”, where a token is “passed” between the different stations and
“taken” by a particular station if information is to be sent by it. There are
three different DP-protocols. The one used in the SIMATIC system is DP-V1
which supports features such as fail-safe (more about fail-safe in Section 2.8.5).
Each object connected to the PROFIBUS-DP network has a unique id in
between 1-127 where 0 is reserved for so called broadcast operations (sending
information to several nodes at once).
2 A node is a PROFIBUS station with a unique PROFIBUS address such as PLC’s, sensors
and actuators.
2.4 MPI 7
2.4 MPI
MPI[4], Multipoint Interface, is a closed Siemens standard. It is used as a
programming interface for S7 PLC’s (see Section 2.7 for information on S7
PLC’s), but can also be used as a interface to operator panels simultaneously.
Each MPI interface, or node, is identified by an address.
2.5 The Siemens SIMATIC totally integrated automation

system
The Siemens SIMATIC concept (“SIMATIC”) is a product line of both hard-
ware and software products for plant control applications.
The SIMATIC system itself is independent of the medium used to transport
information, but it supports both MPI (proprietary of Siemens) and PROFIBUS
standards, as well as Industrial Ethernet. The various communication interfaces
can be used at the same time, combining them, depending on the configuration
and system needed.
A core product of the SIMATIC system is PCS7 which is a software suite
(Process Control System 7) that is needed to build the programs used in the
process plant control. Each control system is then loaded onto a S7 PLC box.
The S7 PLC is set in run mode and then starts to interchange information with
the surrounding objects through the various interfaces available (a more detailed
description is provided in the next coming sub chapters).
It can be discussed if the software or hardware should be explained first
in this thesis, since they are so closely related. The reader should be advised,
however, that there is no clear distinction between the hardware and software.
2.6 SIMATIC hardware

The SIMATIC hardware suite consists of a line of hardware modules used to
build the entire plant control system, from top to bottom.
At the core is the S7 PLC boxes which are used to control the plant process.
Around these S7 PLC boxes the network is built, both using Ethernet, PROFI-
BUS and MPI interfaces, depending on what, and where to connect peripheral
equipment such as operating stations and engineering stations DP-slaves and
even other PLC’s.
Another integral part of the systems are, as already mentioned above, DP-
slaves. The DP-slaves controls the process objects of the plant, and communi-
cates to the S7 PLC’s via a network.
2.7 Engineering and operator stations

A operator station is a computer were the turbine is controlled and monitored.
There usually exist more than one of these so the engineer can see several
processes simultaneously.
At the engineering stations the service personnel can make change to the
control program and test these news changes. There usually exists only one of
these.
8
2.7.1 S7 PLC’s
The S7 PLC’s differ in function, speed and memory capacity. The configura-
tion needed is dependent upon the application. Processes such as conveyor belt
systems with few stations could settle with a simpler S7 PLC’s, while more com-
plex systems such as turbines and paper machines could need several powerful
S7 PLC’s working together as a cluster or separate, dividing the handling of
DP-slaves and the calculations needed to run the plant process.
The most basic S7 PLC hardware configuration consists of the following:
• Rack (“UR2”) - Where the hardware components are mounted.

• PS - Supplies power and provides battery backup if the system should
happen to lose power.
• CPU - The central unit which runs the PLC program stored on a memory
card.
• CP - The communication processor module used to interface with Ether-
net.
The PS, CPU and communication process modules are placed in a UR2 rack.
The UR2 rack is both a mechanical and electrical “backplane”. The rack lets
the different components communicate with each other as well as provides a me-
chanically stable platform for use in harsh industrial environments. Depending
on the type of the rack it can mount multiple “PLC cells”, where each group
consists of a power supply, CPU and communication processor.
The PS supplies power to the rack through the backplane. The PS also
consists of two batteries (rechargeable), which are used if the regular power
from the grid is lost, thus creating redundancy. The S7 PLC program itself
is stored on a flash memory card, which holds the information, even during a
power loss. Although, the configuration data which holds information of what
kind of components that is mounted on the rack, is stored in a volatile RAM
thus making PS redundancy important via the batteries.
Another source of redundancy can be created by adding a extra PS to the
rack. For these purposes, and depending on the saftey needed, there are different
types of PS such as redundant and non-redundant. Obviously, creating a non-
redundant solution is a solution with low initial costs, but could be proven a
fatal decision afterwards, due to production loss caused by downtime of the
PLC-system.
The CP modules is in many ways like a normal network interface card
(“NIC”) found in any modern PC, thus having connections for ethernet wiring.
Since Industrial Ethernet (a subset of Ethernet) is very much like normal Eth-
ernet the wiring can be connected to switches and hubs like any other computer
network. The engineer can then program the PLC through the CP cards in-
terfaces as well as through the MPI interface as mentioned earlier. Also, the
ethernet interfaces are often connected to the ES and OS stations where the op-
erator can control the plant through the S7 PLC. There are CP modules which
holds fiber optic connectors thus handling fiber optic nets if the S7 PLC needs
to process time critical data and process objects.
At the heart of the plant control is the CPU module(s). It consists of a CPU,
and a memory module. The memory module size needed depends on the size of
2.8 SIMATIC software 9
the plant control program it needs to store. Also, depending on the model type
of the CPU module it can be exchanged for larger modules (varying between
1-16MB).
The CPU module also holds a DP interface and a combined DP/MPI in-
terface. The MPI can be used to programme the CPU modules flash card via
an expansion card in a PC. Usually, though, the memory card is programmed
through the CP modules Ethernet connection (that is via a network).
It is through the DP interface that the DP-slaves are connected. That is, the
DP interface handles the process objects communication (see next sub chapter
for a more throughout description). As with the other kinds hardware modules
detailed above there are different types of CPU’s available, varying in speed and
capabilities such as redundancy and fail-safe (see Section 2.8.5 for an explanation
of fail-safe).
2.7.2 DP-slaves explained

A DP-slave is a hardware process object which handles the communication
in between the S7 PLC and the sensor, actuator, drive or any other type of
measurement point located in the plant or process hierarchy. Each DP-slave
has a unique PROFIBUS node id, between 1-127, as mentioned before. The id
itself can usually be set by DIP-switches directly on the device. The name itself
is derived from the fact that the objects use the PROFIBUS-DP° R
protocol to
communicate with one or more master (S7 PLC box(es)).
Each PLC box are also considered to be a node in the system and is therfore
assigned a node number. By default a S7 PLC usually assigned node id 2 (id 0
is reserved for broadcast packets).
The DP-slaves are connected via a PROFIBUS interface (cable) to a S7
PLC. Each slave can hold a variable number of I/O’s and types such as a 16
analog signals input or 4 input digital signals output matrix.
The slaves can be connected in serial to the same S7 PLC using the same
cable and interface. As with the S7 CPU there are fail-safe, redundant and
fiber-optic versions of most DP modules.
Industrial processes, such as a turbine may involve more than twenty DP-
slaves in the plant network containing hundreds of signals, while even more
complex plant processes such as a paper machine may contain thousands of
signals and an even larger amount of slaves.
2.8 SIMATIC software

With the hardware explained briefly, one should note that the software of the
SIMATIC suite is just as important and, sometimes, overly complex. The
SIMATIC software suite consists of a plethora of components. While some
are a integral part in this thesis, other, are not, thus these are excluded. Only
the most important programs which the authors has used, are explained below,
to make the thesis as easy as possible to grasp.
SIMATIC software has been developed and used since the DOS days (late
80:s), before Windows. Since each new revision of the system, it has been up-
dated, upgraded and reworked. Although, not from the bottom and up, rather,
the other way around. This has created a non-modern suite of components
which are not very easy to use. SIMATIC and the components are, to say the
10
Figure 2.3: Two Siemens SIMATIC S7 PLC boxes (back) connected to DP-
slaves (front).
least, software built on old concepts which the developers have tried to fusion
with new ones such as drag and drop and GUI. Therfore, SIMATIC is relatively
hard to work with initially, creating a steep learning curve for beginners.
A summary of the programs explained are included in the list,
• SIMATIC manager - All-in-one control center for the SIMATIC suite

of programs.
• WinCC - OS and ES station development and usage.
• Hardware config - Configuration of the hardware setup, used in the

factory process, at all levels.
• Continuous function chart editor - Drag and drop editor where func-
tion blocks are interconnected to create the PLC functions (i.e. PID reg-
ulators, logic blocks et.c.).
• Sequential function chart editor - Program used to build sequences

using function blocks (very much like flow charts).
• PG\PC interface - Sets the interface used when programming the CPU
module.
• NetPro - Program to set up communication between PLC’s and OS.
2.8.1 SIMATIC manager

SIMATIC manager is the control center in SIMATIC used to organize, set up
and develop the software projects from a central point. Each and one of the
other programs in the SIMATIC suite is started from the manager itself.
Since building a control system often needs a team of people collaborating
SIMATIC manager makes use of multi-project concepts which enables engineers
to simultaneously develop the models and control systems, also known as con-
current engineering.
2.8 SIMATIC software 11
The manager shows projects currently open, a summary of the hardware

configured for the projects, and the different components included in the control
program.
The manager also shows connected DP nodes (masters and slaves) for an
easy overview of the connected devices, making diagnosis and detection of error
more manageable.
Since most plant applications include more than one PLC controlling the
process, more than one PLC program, at a time, can be loaded in the manager.
2.8.2 Hardware config

The hardware config editor is reached from the SIMATIC manager. This is
where the engineer sets up the entire hardware network, concerning everything
from what kind of PLC to use to the type of media interconnections between the
nodes and where the OS and ES stations should be connected in the automatic
control system network.
Figure 2.4: Basic configuration with a DP-rack in the hardware config editor
In Figure 2.4 a hardware setup can be seen as defined by the hardware

configuration editor. The window to the left in Figure 2.4 represents the com-
ponents which the engineer have physically mounted on the UR2 rack. Since
there are different kinds of S7 CPU’s, CP’s and PS’s the correct version must
be configured. Each number in the window corresponds to the slot on the rack.
As seen, the CPU and the PS is mounted in two slots each.
To the right, on the “PROFIBUS cable”, a DP-slave is mounted. In this
case a IM153-2 slave, which holds 16 analog out signals (cannot be seen in the
figure). This example illustrates a minimal system with very few signals but is
nevertheless a good example of how a plant network could be built using the
hardware config interface.
2.8.3 SFC editor

In the sequential function editor the engineer builds the sequences in which the
turbine should be started. In other words, in which order the CFC charts should
be executed in order to start up the turbine in a controlled way.
The editor also includes transition steps which has to be fulfilled before the
sequence continues. The sequences, which is mentioned more in detail in the
sub chapters of chapter 2.11, is built in the SFC editor.
12
2.8.4 CFC editor

The continuous function chart editor is where the engineer builds the actual
control program. Components such as PID-regulators, OR-blocks and timer
functions can be dragged-and-dropped into the editor. The components can
then be configured and connected to their respective I/O ports.
There are two kinds of fundamental “low-level” blocks in the editor; fail-safe
and normal blocks. The fail-safe blocks have a distinct yellow color while the
others are grey as seen in Figure 2.5.
The blocks seen in Figure 2.5 has the function of being out and input blocks
out and into the PLC itself. The blocks are thus the “boundaries” of the PLC
program.
Figure 2.5: Two typical CFC-blocks, normal (left) vs. fail-safe (right).
2.8.5 NetPro
This program is used to set up the communication in between the PLC’s and the
operator station(s). In addition to hardware config where the communication is
initially set up, this program modifies the necessary “blocks” to ensure that the
communication in between the PLC and OS works correctly concerning message
and alarms sent between the process, PLC’s and OS.
2.8.6 Fail-safe versus non fail-safe

A fail-safe block differs from the non fail-safe ones in a few important aspects.
First of all fail-safe blocks needs special CPU’s known as H-series modules. If
this is not the case the control program cannot be loaded, at all, into the CPU’s
memory module. Typically, fail-safe-able modules are more expensive than their
non fail-safe counterparts, this is why the engineer should consider the pro’s and
con’s of using fail-safe versus a more low-cost setup.
A fail-safe block switches to an alternate value and sets the output of the
block (that is, a value going into the process to a DP-slave) if a fail-safe mode
should happen to be enabled. The fail-safe mode can be set for a number of
reasons, such as the DP-slave failing electrically or if the cable is failing to deliver
the signals to the CPU’s DP-interface (i.e. no acknowledgement is received from
the DP-slave of the packets safe delivery).
Fail-safe is mainly used in plant processes with sensitive components which
could be damaged if the signals are lost. For example mechanical systems such
as gas turbines. Fail-safe are also used in explosively classified environments
such as oil and gas platforms.
2.9 The Siemens SIMIT simulation system 13
2.8.7 WinCC
WinCC, or Windows Control Center, is the program where the operator pictures
are built in. The connections to the signals from the CFC-editor is connected
to GUI components in WinCC such as buttons, diagrams, pictures and sliders.
WinCC can be run on multiple PC’s known as operator stations (“OS”)
which makes it easier to have an overview of the gas turbine process and to
control it through the GUI.
2.9 The Siemens SIMIT simulation system

The Siemens SIMIT simulation system is a program suite used for plant sim-
ulation and modelling. It has an easy to use interface, in many ways similar
to Mathworks Simulink (included in Mathworks Matlab). SIMIT is a real time
simulation system, that is; simulation of the models and analysis of the data is
done in real time (although the data generated can be saved), while programs
such as Simulink can simulate the entire model instantly and let the engineer
analyze the model and its results at once.
Clearly, this has its pro’s and con’s. It’s harder to know and estimate how the
simulation is expected to develop and expand as time increases since SIMIT and
SIMATIC has to interact and calculate values such as PID-controller settings
dynamically as the process evolves.
SIMIT has been designed for less complex models in mind, as the user would
notice rather quickly. Still, more advanced programs are possible, as seen by
this thesis.
2.9.1 SIMBA Pro
The SIMIT suite can be extended with a SIMBA Pro PCI card (“SIMBA”). The
card itself is fitted into a PCI slot in a PC and accessed via a special software
which SIMIT uses to relay its information flow through to the PCI card itself
(through the use of a hardware driver). The schematic view of SIMIT combined
with the SIMBA Pro PCI card is seen in Figure 2.6.
SIMBA Pro has two connectors. Each can be connected to a PROFIBUS
network, which means the card can handle two networks at the same time.
SIMBA Pro does not need SIMIT to function as it is a self-reliant system.
SIMIT should be seen as an add on containing more advanced graphical GUI
and better analysis tools. SIMBA Pro holds several tools and components to
be able to simulate simpler processes.
The values of the I/O ports of the DP-slave can also be set individually if
needed. Since SIMBA Pro is built for S7 communication through PROFIBUS
the DP-slave configuration can be easily imported into SIMBA Pro from the
SIMATIC hardware config program. A list of a imported DP-slave configuration
can be seen in Figure 2.7.
SIMBA Pro also handles fail-safe DP-slaves by adding extra signals for the
fail-safe to be turned on or off for each signal in the hardware config configured
in the fail-safe mode.
14
x86 Simulator PC with Windows 2000
SIMBA Pro Driver SIMBA Pro PROFIBUS-DP

S7 PLC
Software PCI card
SW Interface
SIMIT
Figure 2.6: SIMIT and SIMBA Pro interaction scheme (OS and ES computers
connected to the S7 PLC are not included).
Figure 2.7: SIMBA Pro list of configured DP-slaves.
2.9.2 Using SIMIT

Although the GUI has not been designed with ease of use in mind, managing
SIMIT is fairly simple. SIMIT consists of basic component types such as tanks,
PID-regulators and digital logic which simply is dragged, dropped and connected
together to achieve the needed function (as in for example Simulink). The
components can then be connected to signals coming from the S7 PLC, through
the SIMBA Pro card, via input and output elements known as peripheral blocks.
The signal list in SIMIT can be imported from the PLC program in the
SIMATIC system, thus not needing to enter the signals by hand. Since there
can be hundreds of signals this is a very convenient feature.
2.10 The Siemens GT10C gas turbine 15
Each signal has a hardware address and an alias assigned to it (this is done
during the development cycle of the PLC program in SIMATIC). The alias is a
name used when connecting I/O ports in SIMIT to simplify the process since
only a hardware address would be confusing and rather cumbersome.
A very simple example is shown in Figure 2.8 where two input signals, IN-
PUT SIGNAL 1 and INPUT SIGNAL 2, is added together. The result is
sent through a sin block, and finally output to the OUTPUT SIGNAL port.
More complex concepts such as feedback (PID-regulators) are also available to
the engineer.
Figure 2.8: Example of a SIMIT diagram/modell.
SIMIT differentiates between what it calls operator screens and diagram

screens. This is very much like the concept of SIMATIC. The logic and functions
of the simulation is built in the diagram view, using, as explained, components
of various types. The components are then connected to the operator screens
which displays and presents the values the diagram screen produces during the
simulation. The DISPLAY component seen in Figure 2.8 is such a component.
The DISPLAY component is simply dragged to a operator screen and
the output is then displayed at this screen during the simulation. Interactive
switches and buttons can also be added to the operator screens to control and
influence the diagrams, yet, analogous to SIMATIC.
Custom components can be made in SIMIT thus reducing the need to con-
nect large clusters of blocks to achieve the desired functionality. The program-
ming language is proprietary to SIMIT but very similar to object oriented syn-
tax.
2.10 The Siemens GT10C gas turbine
The theory explained here is in no way meant to be a comprehensive description

of how an actual turbine works down to the very core, rather, it should be seen
as an overview.
Some concepts, tables and formulas in the following sub chapters are taken
from internal Siemens documents, thus there are no reference to these in the
text.
A gas turbine core engine can be decomposed into three different parts;
compressor, combustion chamber and power turbine. This can be seen in Figure
2.9.
16
Figure 2.9: The GT10C gas turbine is a turbine with two rotors, the compressor
rotor and the power turbine rotor. This type is known as a double shaft turbine.
The three main parts of the turbine is enclosed in red.
2.10.1 Compressor
The function of the compressor is to compress the surrounding air. When the
air is compressed the temperature and pressure increase. To avoid surge3 in
the compressor, two bleed valves, are used as well as an inlet guide vane (IGV).
These elements can be seen in Figure 2.10(BV1 and BV2).
The IGV controls the amount of air that flows into the compressor. The bleed
valves are used to level out the pressure in the compressor to avoid fluctuation in
the pressure, which is an unwanted effect. BV1 is just an ordinary on/off valve
and BV2 is a control4 valve. BV2 is connected to the air inlet through piping,
this to be able to control the temperature in the combustion chamber. At a
higher flame temperature the emissions are lower. The CO and N Ox values
decrease and the turbine is in that way more environment friendly.
BV1 is used only during the start of the compressor and closes when the
speed Nnorm of the compressor reaches 6800rpm. BV1 is fully closed between
6950rpm and when stopping the turbine it remains closed until 400rpm.
r
288
Nnorm = N · (2.1)
t2 + 273
The relation Eq. 2.1 between the valves position and speed is later used in
the SIMIT modell to verify a stable operation mode of the compressor. That is,
if the simulated values is out of range, the turbine control system would trip5
since the model is not working as expected.
To ensure stable operations and required engine performance, the compressor
guide vanes must be controlled according to Table 2.2. P3 is the compressor
discharge pressure (M P a) is calculated as an average of three different pressure
transmitters.
3 When a surge occurs the compressor stalls, that is, stops to work.
4A control valve lets the PLC control the exact position of the valve, that is, how much it
should open.
5 A trip of a turbine is when the control program shuts the turbine down because of errors
(signals outside the safety limits set up by the control program).

2.10 The Siemens GT10C gas turbine 17
Figure 2.10: The compressor valves locations of the turbine.
P1 is the compressor inlet pressure (M P a). The surge protection is activated

when the speed exceeds 6000rpm.
Nnorm (rpm) P3/P1

≤ 6000 1.0
6500 2.5
7500 4.8
8700 7.6
9800 13.8
≥ 10500 14.2
Table 2.2: Speed versus pressure ratio in the compressor.
To detect compressor surges, the compressor operating line is supervised. If

the compressor pressure ratio is lower than in Table 2.2, a surge is likely to have
occurred and a trip will be initiated.
When the compressed air has passed through the compressor it reaches the
combustion chamber.
2.10.2 Combustion chamber

In the combustion chamber the compressed air and the ignited fuel help increase
the pressure even more. The combustion chamber contains a ring with fuel
burners which are constructed in such a way that the flame is rotating. This is
to maintain a flame that keeps the same shape, if not a pulsation effect could
occur, when the flame flickers. This in turn result in high vibrations, high axial
displacement and damage to the turbine.
The amount of fuel inserted into the combustion chamber is controlled by
two gas fuel control valves. The primary gas fuel control valve is used in the
start sequence and split range controlled with the main gas fuel control valve.
The primary gas fuel valve is at nominal speed closed to a minimum of “stay-
alive” percentage opening, this to avoid flame extinction if the gas generator
18
low load high load

main heatflow primary heatflow primary heatflow
pos. (%) (M J/s) pos. (%) (M J/s) pos. (%) (M J/s)
0 -2 0 -2 0 -2
8 0 20.5 0 20.5 0
15 4.9 25 2.7 25 1.48
20 10.5 30 5.46 30 3.86
25 17.6 35 9 35 7.98
30 25.7 40 13.78 40 12.47
40 43.9 50 20.8 50 20.8
45 53.2 55 25.3 55 25.3
50 62 60 30.18 60 30.18
55 70.2 65 32.98 65 32.98
60 77.2 70 36.19 70 36.19
65 82.8 75 38.89 75 38.89
70 87 80 40.98 80 40.98
75 92.1 90 42.98 90 42.98
80 97.2 100 45.2 100 45.2
Table 2.3: Valve characteristics.
deceleration control (GDC) goes active. The GDC is activated if the load6 on
the turbine is lost due to an malfunction.
When the high pressurized warm air expands through the compressor the
kinetic energy is transformed to mechanical energy by the turbine blades and
increase the speed of the compressor, thus if the air and heat flow through the
turbine is not controlled the compressor would accelerate rapidly. The heat
flow value can be derived from the fuel gas valves characteristics when a certain
percentage opening generates a certain heat flow. The characteristics of the gas
fuel valves can be seen in Table 2.3. The valve characteristics is used in the
control program of the turbine (that is, in the SIMATIC system) and also in
the SIMIT model to obtain the heat flow value. The heat flow now expands and
continues through the power turbine.
2.10.3 Power turbine

Because the exhaust pressure is lower than the pressure in the combustion cham-
ber the warm air now expands further through the turbine blades. The energy
of the heat flow is once again transformed from kinetic energy to mechanical
energy thus the speed of the power turbine increase in correlation to the heat
flow value.
The power turbine has an inertia which has to be conquered in order for the
power turbine to start accelerating. As the power turbine is now turning the
only thing missing is the actual load which can be a generator or a mechan-
ical drive. Usually the mechanical drive application is a compressor used for
compressing gas in pipelines, but there is also mechanical drives, as mentioned
6 The load is the equipment which the turbine drives, such as a water jet in a boat (this
is not entirely accurate since it does not drive the water jet directly, rather it uses something
called a mechanical drive in between).
2.11 Turbine regulators 19
before, connected to water jet propulsion systems like the Stena Carisma ferry
over Öresund.
2.11 Turbine regulators

The regulators role is to ensure that the turbine never reach a damageable
operation mode.
In normal operation the following regulators are used,
1. STC
2. NGGL
3. SC
4. T7L
The other controllers are used to monitor that this happens in a controlled
way. What the different regulators monitor can be found under the respective
regulator heading in the text bellow.
These regulators are,
1. STC - starting control
2. NGGL - gas generator speed limiter
3. SC - speed controller
4. T7L- exhaust average temperature limiter
5. T7Li - exhaust inner temperature limiter
6. MPC - maximum servo position control
7. GAC - gas generator acceleration control
8. GDC - gas generator deceleration control
9. PAC - power turbine acceleration control
10. LLD - loss of load detection
2.11.1 STC - starting control

In order to accelerate the gas generator at a limited rate, the starting control
produces a set point for the desired heat flow as a function of time. It thereby
prevents too rapid acceleration and thermal stress of the turbine. The set points
is ramped from ignition level with a certain speed. The STC function controls
the gas fuel servos until the NGGL function takes over.
2.11.2 NGGL - gas generator speed limiter

The NGGL controls the gas generator speed from 5600rpm and up to a certain
speed where the speed controller takes over. It also controls that the gas gen-
erator does not exceed maximum allowed speed. When the gas generator speed
is more than 5600rpm the set point is ramped with a max setting of 40rpm/s.
The set point has no manual mode and the operator is not able to change it.
20
2.11.3 SC - speed controller

The speed controller takes over at minimum speed of the power turbine at
3250rpm. The set point to the controller is set by the operator in automatic
mode or received from the compressor performance controllers. This controller
is normally in operation until full load is achieved when T7L (or NGGL) takes
over. The feedback to the speed controller is the power turbine speed. The SC
controller also makes sure that the power turbine maintains the correct speed.
This to ensure that the correct flow and pressure in the pipelines are maintained.
2.11.4 T7L - exhaust average temperature limiter

T7L controller monitors the exhaust temperature so that the temperature does
not get to high and damages the turbine.
As the load increase the exhaust temperature increase. The T7L controller
limits the exhaust temperature which is the normal maximum load limiter. The
set point is a function of ambient temperature, ambient humidity, compressor
delivery pressure, exhaust gas pressure and compressor inlet pressure. If the op-
erator selects peak load the set point is automatically adjusted to a higher value.
The feedback to the T7L controller is the turbine exhaust average temperature.
In an ideal world it should be sufficient with these controllers but in the
real world it is also necessary to make sure that other operating modes which is
damageable in the long run never occurs. This is why there are six additional
controllers.
2.11.5 T7Li - exhaust inner temperature limiter

The T7Li controller monitors the inner temperature so that the temperature
does not get to high and damage the turbine.
T7Li limits the inner exhaust temperature. This protects the turbine from
high exhaust temperature if the combustion chamber bypasses malfunctions.
2.11.6 MPC - maximum servo position control

MPC limits the maximum fuel input. The operator sets the set point in M J/s.
Normally the set point corresponds to more than 100 per cent load. MPC is as
mentioned earlier not used at normal operation but the operator can manually
limit the maximum amount of fuel fed to the combustion chamber. It is also
used as backup control upon feedback error. The error freezes the actual desired
heat flow signal and it becomes the set point for the MPC controller.
2.11.7 GAC - gas generator acceleration control

GAC shall prevent the turbine from surging and from transient over tempera-
tures in the gas generator during loading. The set point is a function of nor-
malized gas generator speed. The operator is not able to change the set point.
To avoid overheating and compressor surge, there is an upper limit of the fuel
flow, set by the actual normalized compressor speed.
To prevent damage on the engine in mechanical drive applications there is
a loading limitation on compressor discharge pressure increase, as a function of
2.12 Automated start of turbine 21
power turbine speed variation. The register is valid for all matching options;
the points in between are linear interpolated.
2.11.8 GDC - gas generator deceleration control

To avoid flame out, there is a lower limit of the fuel flow, set by the actual
normalized compressor speed. This is also valid for power generation. It is
also necessary to increase the GDC level for mechanical drive applications. It
is increased with required fuel flow to match the base load at minimum speed,
after that the minimum speed has been reached.
2.11.9 PAC - power turbine acceleration control

In order to accelerate the power turbine at a limited rate, the power turbine
acceleration control limits the set point for the desired heat flow as a function
of power turbine acceleration. It thereby prevents too rapid acceleration and
thermal stress of the power turbine. The set point is fixed during start up
and put aside during operation. The feedback to the PAC limiter is the power
turbine speed.
2.11.10 LLD - loss of load detection

The function of the loss of load detection is to sense the power turbine speed
value, and calculate the rate of change over one sample. If it exceeds a certain
level the fuel level is set to GDC level at maximum speed and BV2 is opened
to brake the gas generator speed/load.
2.12 Automated start of turbine

Because of the complexity of the turbine different start up sequences is used to
ensure that all systems are started and set to their operation levels. There are
three different sequences which a mechanical drive turbine has to go through
before it is up and running.
2.12.1 Unit sequence

The unit sequence is a start/ stop sequence with 26 steps. The main purpose
of this sequence is to start up different systems: such as lube oil, ventilation
etc. Table 2.4 shows the steps included in the sequence. Some of the steps are
enclosed in a function group which in turn uses a lot of signals. As an example
the lube oil function group has to start two of three pumps, the function group
also monitor that the lube oil has the correct temp, pressure and level.
2.12.2 Gas fuel sequence

The gas fuel sequence is used for leakage test of the two gas shut off valves. It
also controls that each one of the gas fuel control valves is working properly with
different set points which the valve has to reach in a certain time. The sequence
also sets the start position for the gas fuel valves. The gas fuel sequence includes
nine steps. Table 2.5 shows the complete gas fuel sequence.
22
Unit Sequence Type off

(step) description
Start Start of unit sequence
Step 1 Start preparation FG
Step 2 Cooling water on
Step 3 Lube oil FG on
Step 4 Ventilation FG on
Step 5 Reset trip system
Step 6 Prepare compressor
Step 7 Jump to step 9 if trip system reset
Step 8 Reset trip system
Step 9 Compressor piping pressurized
Step 10 Start turbine sequence, continue at turbine in service
Step 11 Spare
Step 12 Spare
Step 13 Unit in service until ordered off
Step 14 Start preparation FG off
Step 15 Spare
Step 16 Stop gas turbine
Step 17 Stop compressor
Step 18 Deactivate turbine and compressor sequence
Step 19 Unit standby
Step 20 Compressor unprepared
Step 21 Deactivate ventilation
Step 22 Deactivate lube oil
Step 23 Deactivate water cooling
Step 24 Spare
End End of unit sequence
Table 2.4: The unit sequence which starts up turbine.
Gas fuel sequence Type off

(step) description
Start Start of gas fuel sequence
Step 1 Primary fuel gas control valve check
Step 2 Main fuel gas control valve check
Step 3 Start position of fuel valves check
Step 4 Ventialtion position check
Step 5 Isolation valve leak test
Step 6 Open shut off valve ignition burner 6
Step 7 Start position check
Step 8 Main ignition
Step 9 Gas in operation
Step 10 Close isolation valve
End End of gas fuel sequence
Table 2.5: Gas fuel sequence.

2.12 Automated start of turbine 23
2.12.3 Turbine sequence
This sequence initiates the purging of the turbine. The turbine needs to do
a purging before start to ensure that there is no gas trapped inside it. The
sequence is also used for accelerating the turbine with help of the start motor
after ignition. After 5400rpm the start motor is disengaged and the turbine is
now accelerating by itself, by controlling the gas fuel valves. This sequence also
monitor when the ignition starts and ignites the fuel gas by looking at pilot flame
and main flame indicators. The turbine sequence includes nine steps. Table 2.6
displays a complete list of all the steps included in the turbine sequence.
Turbine sequence Type off

(step) description
Start Start purge FG, fuel prep FG, stop cooling
Step 1 Start pilot ignition
Step 2 Start startmotor, main ignition, stop purge
Step 3 Acclerate with startmotor, start emergency lube oil,
stop pilot ignition
Step 4 Acclerate without start motor, stop start motor
Step 5 Turbine in service
Step 6 Stop gas turbine, flame out, stop fuel
stop emergency lube oil, start cooling
Step 7 Reset turbine sequence
End End of turbine sequence
Table 2.6: Turbine sequence.
2.12.4 A start of the turbine using the sequences
In the start of the gas turbine the unit sequence is activated first, the sequence
executes each step when the transition criteria are fulfilled. When the sequence
enter step 10, ventilation and lube oil systems are activated and running, the
compressor is ready for start. The trip system is also reset and operative. Now
the turbine sequence starts at step 1. This step also starts the gas fuel sequence
which runs through the valve check and leakage test. At the same time the
compressor turbine has purged the turbine for 75 seconds at 2300rpm and also
increased the speed to 2600rpm which is the speed of ignition. Pilot ignition
is initiated and the compressor turbine accelerates with help of the start motor
until 5400rpm where the start motor is disengaged, in the mean time the main
ignition also has been activated. The turbine exhaust temperature increases
rapidly to 400 degrees centigrade. The gas fuel sequence has now reached step 9
and will maintain this step until a stop is initiated. Now the turbine accelerates
by itself only using the gas fuel valves, the turbine sequence now reaches step
5 and the turbine is in service. When the heat flow value is over 17.77M J/s
the power turbine starts rotating and accelerates controlled by the turbines
ten controllers to a speed of 3250rpm. The unit is now in service and the unit
sequence has reached step 13. It is now up to the operator to set the appropriate
speed of the power turbine or use the set point set from the compressor PLC.
24
2.13 Summary
A short summary, and quick facts list follows. It is not meant to be comprehen-
sive; rather it should be used as a reminder on what the chapter is about.
Since the THEORY part is very important to get a firm grasp of the de-
tails explained and discussed the reader should feel that he or she is somewhat
familiar with the words and concepts in this summary before proceeding.
• PROFIBUS is the medium used to send information from and to DP-slaves

in the plant.
• PROFIBUS connects through the DP interface of a S7 CPU module.
• S7 and PROFIBUS is a distributed system built on modern network tech-
nologies.
• A S7 rack (UR2) typically consists of PS, CPU and CP modules.
• The CPU module holds two DP and one MPI interface (shared with one
of the DP interfaces).
• The CP module communicates via Ethernet (fiber optics or electrical sig-
nals).
• The CP module handles communication with OS and ES stations.
• There are two fundamental types of building blocks in the CFC-editor,

fail-safe and non fail-safe.
• DP slaves controls the process objects (such as motors and sensors) and
sends the information through the DP interface (cables) to the S7 PLC.
• Each signal in the PCS7 system have a unique address’ depending on the
DP-slave address.
• Each unique address has a signal name alias to make it easier looking up
and working with signals rather then using the address’.
• The engineer can program the CPU from both the MPI and Ethernet
interface depending on the situation.
• The SIMBA Pro card holds two PROFIBUS interfaces which can be di-
rectly connected to the S7 CPU’s DP interfaces.
• The SIMIT simulation system is a real time system and the GUI is very
similar to Mathworks Simulink.
• SIMIT uses SIMBA Pro and the PCI-card through a software interface to
communicate to a S7 PLC.
3 DECIDING THE SIMULATOR SETUP 25
3 DECIDING THE SIMULATOR SETUP

The following chapter describes how the simulator was developed. This includes
initial analysis of what system and solution to use and how to build the simulator
itself both soft- and hardware wise.
3.1 Different solutions

The first steps of the initial analysis was to devise what kind of solution to use
for the simulator. A number of conditions had to be met,
• The investment costs had to be reasonable.
• The simulator hardware had to be fast enough to be able to simulate a

gas turbine.
• PROFIBUS communication between the simulator and the turbine PLC

boxes should be simulated if possible.
• It should be easy to modify and develop in future engineering projects.
This thesis revolves around the GT10C gas turbine, but since there is a need
to extend it to other models, one of perquisites would be to make the simulator
easy to modify and re-engineer when needed. Each delivered turbine comes
with “options”, that is, specific parts which the customer decides. This makes
each turbine unique thus the simulator should be able to be modified to handle
all these different “options” as they are ordered by the customer. Therfore it
should be easy to understand and change the simulation system itself, although
the basic knowledge of automatic control and the SIMATIC system should be
known.
If the PROFIBUS communication between the PLC and the simulator should
be tested, the simulator cannot be in the same PLC as the control program. As
it is now a test can be done using the program in the PLC to try out different
parts of the control system. But since this is only local, the communication in
the cables will not be tested, thus, propagation time, delay and other factors
will be left out of the test making the results inconclusive compared to a real
test of the control program against a turbine.
If the PROFIBUS communication could be included, somehow, all the im-
portant PROFIBUS factors mentioned above could be taken into account to
check if the control program is feasible and also making the simulator more
accurate.
Making sure that the hardware used for the simulator is fast enough to
handle all the signals is also an important factor. Although, it is very difficult
to conclude if the simulator setup finally chosen will be able to handle the load
done by the control program, therfore, one have to do an estimation if it is
possible.
Another important feature of the simulator is to be able to use the original
OS pictures which the engineers at site uses to control an actual turbine with.
That is, it is not just enough to simulate the signals the control program excepts.
It’s also important to be able to use these operating pictures to “control” the
simulator as one does with a turbine. Thus, if both the turbine and the simulator
26
is seen as two black boxes the engineers should be able to “switch” these and
the person operating the turbine should notice no difference at all.
Initially there were discussions between four different solutions (as the su-
pervisor of this thesis suggested). These were devised before the actual thesis
work begun, thus it was not known if they were possible to implement or not;
which is the first thing this thesis will discuss.
The fifth solution was developed at a later stage after tips by SIMATIC
consultants at Siemens.
3.1.1 Solution I - PLC—PLC

The first solution involved two PLC’s connected to each other via the proper
interfaces. The first S7 PLC is the turbine PLC where the control automation
program is located. The second one holds the actual simulator of the turbine.
Therfore, the simulator would be built in the same environment as the turbine
control program by using SIMATIC tools.
A few questions involving this idea could be asked,
• Can there be two masters on the same buss (cable)?
• Cost of having the simulator in another PLC
• Can the S7 PLC handle a simulation program in respect to memory avail-

able and the speed of the internal CPU of the PLC itself?
The cost of another PLC is a major disadvantage. Since the PLC’s are de-
signed to work in rugged industrial conditions they are more expensive. A PLC
costs somewhere around 100KSEK and would thus result in large expenses.
One could argue, however, that the PLC being used to develop the simulator
software latter could be used in a turbine project where it is actually needed,
that is; reused. Thus, just pushing back the investment cost to an earlier date
than needed for an actual turbine project (which would lie forward in time).
If the simulator is to be sold to a third party (as a product) the expense of
the entire setup cost would be to large if a dedicated PLC is to be used for the
simulation.
After some more research into this solution the authors of this thesis came to
the conclusion that it is not feasible. This is mainly due to one single reason; one
have to change the control program itself. Adding and removing features from
the control program would be dangerous and could cause unnecessary confusion.
Obviously, simulating the turbine without changing the control program is the
only solution accepted (that is, if there is no other possible ones, but since there
are this condition can be set).
To bypass this, a possible fix could be to somehow connect the S7 PLC’s
to a PC and program a software which would act as a “switch” and change
the packets being sent and reroute them to the simulator and the other way
around. This is certainly possible but would take extensive time to implement,
surpassing well over 20 weeks, which is the time frame that the simulator should
be developed within.
Thus this solution was discarded at an early stage. See Figure 3.11 for an
schematic of this solution.
3.1 Different solutions 27
Cable
PSU
PSU
DP
CP
DP
CP
S7 S7
Turbine Control System Simulator
Figure 3.11: Solution I, PLC to PLC communication (simplified schematic).
3.1.2 Solution II - Simulator and control system in same PLC

• Would both the control program and turbine program fit?
• Is the PLC fast enough to handle both programs at once?
• Would the solution mirror an actual turbine in real life since no commu-
nication on physical mediums is used.
Certainly, from an economic perspective this solution would be the best; to

use the same PLC for both the turbine control system and the simulator itself
would result in no direct investment costs for extra PLC’s.
In reality, though, this is not the case. The control program and the simu-
lator program would require extra memory. And because the PLC used for the
control program itself has a limit on how large memory cards it can handle one
have to invest in a PLC that can handle larger memory. This way this solution
would actually result in the need to invest in more expensive PLC’s.
Also, the PLC can not be reused in a latter turbine project because it can
handle more memory than needed (the customer would not accept investing in
a better PLC than needed, creating a more expensive turbine).
Finally, this solution excludes any PROFIBUS communication. This makes
the simulation less real life like and non accurate.
3.1.3 Solution III - PLC—PC/C/C++ (Java)

The questions that should be discussed concerning this solution is,
• What kind of PC would be needed, how fast?
• Is there a possibility (in reasonable time) to make a gateway between

Simulink and the simulator?
• How should the PROFIBUS network, connected to the simulator PLC, be

interfaced to the PC?
The third alternative, using a PLC to communicate with the simulator on

a normal PC would require minimal investment. An ordinary PC have to be
bought, nothing over the top; today’s PC’s are high performance work tools
certainly surpassing even the processor power of a SIMATIC PLC. Thus creating
a simulator program that could respond in adequate time to the PLC software
would be a non-trivial problem.
28
Obviously, the problems with this solution does not depend on the PC speed,
rather it depends on if it is feasible to build a simulator program in a program-
ming language such as C++ from scratch.
Certainly, from the authors perspective, designing a basic program which
includes the elements needed, would be possible. PID regulators, different kinds
of flows, action and reaction elements and so on are so basic that they would
be easily implemented in a object oriented language such as C++ or even Java.
Although, this would take time, designing a software is, with all the unknown
factors involved in this project is hazardous. When a certain point is reached
a not so easy obstacle could show itself (that is an obstacle that could take to
long time to breach), since the exact function of the simulation program is hard
to conceive in just a few months, this has to be a evolutionary process, and the
time at hand would not be sufficient.
The work needed of examining the basic requirements, programming the
simulator, and then needing to implement the elements and connecting these in
the simulator could prove to take to long. When at the same time the authors
had to learn the inner workings of a turbine and other issues revolving around
this.
Although, since some other solutions which the authors were working on
simultaneously were not going too well, the decision was to see if a simple sim-
ulation framework could be programmed. The choice fell on the programming
language Java due to its short development cycle for prototyping simple pro-
grams and its object oriented style (which is ideal for a simulation program
where objects in, for example, a industrial process in involved).
A pre-study began, programming a basic interface for a simulation engine.
At the same time a interface had to be done which communicated via a PCI-
card to the PLC itself. For this reason, a CP5614A2 card was bought from
Siemens. This card can simulate a PROFIBUS slave unit and thus be used by
the program to implement a process object.
After a few weeks of examining the API included with the card, the con-
clusion was that the task of actually implementing the slave simulation would
be impossible because the PCI-card only handled one PROFIBUS slave at a
time, and the simulation program would need at least hundred and more to
work. Another PCI-card could probably have been bought which could handle
more slaves simultaneously but since that would have taken even more time,
and because another solution which seemed to work was being done at the same
time (Solution V – SIMIT), the idea was discarded.
3.1.4 Solution IV - PLC—PC/Simulink
The difference between the C++ solution and the Simulink would be to use
Simulink as a simulation framework instead of C++/Java. The problem with
building a interface to the PLC would still be here, i.e. one have to use a PCI-
card as in the C++/Java-solution. Moreover, one have to learn the SimuLink
C++ interface and adapt it to the PCI-cards API-interface.
This solution was actually dropped at an early stage since it would be to
cumbersome to learn both the Simulink API and a PCI CP-card API.
Cable
PC+SimuLink or C/C++
PSU
DP
CP
S7
Turbine Control System
Figure 3.12: Solution III & IV, PLC to PC (C/C++/SimuLink) communication

(simplified schematic).
3.1.5 Solution V - PLC–SIMIT (chosen)

The last, and final solution, which was latter used, is SIMIT. By tips from
a SIMATIC consultant about the SIMBA Pro card (described in the theory
section) this solution was investigated. The SIMIT solution is a suite with the
purpose of testing the entire factory floor process (or a turbine as in this case,
more can be read in the THEORY section).
Since the interface between the PC program (that is; SIMIT), and the
SIMATIC PLC’s (Simba Pro PCI Card) is already done the time could be
fully focused on understanding the turbine and implementing a working simu-
lator. This solution, however, is far from free. The Simba Pro card itself costs
30KSEK and one license of SIMIT is 50KSEK. And that is just the “basic”
suite. If more objects such as flows and pipes are needed in the model the price
goes up.7
On the other hand, since the problem was lack of time, this solution comes
cheap in the long run. Using SIMIT, the objectives set up could be met in time,
or at least, it is more likely they could be met in time than using any other
solution.
The downside to this solution is the price of just one license. This hinders
simultaneous development by more than one engineer, since investing in multiple
licenses would become to expensive.
A schematic of the PLC–SIMIT solution can be seen in Figure 3.13. The
two PLC’s seen are where the turbines control program reside. The SIMIT PC
is the one simulating the turbine itself.
3.1.6 Conclussions
The final choice is far from obvious. As mentioned in the THEORY chapter,
SIMIT lacks in some areas. The preferred solution would have been using either
a more powerful simulation program such as Simulink or writing a fully new
7 It should be noted, to the confused reader, that, even though this thesis was done at
Siemens, and Siemens themselves are the creators of SIMATIC, internal economic politics
(which says that each department should uphold its own costs) states that the software have
to be payed in full to other departments and companies in the Siemens sphere. I.e. even
though this thesis was done at a Siemens company they still have to pay for Siemens software.
30
program in C/C++/Java. But considering cost versus time the decision was
nevertheless easy to make.
As time progressed it would show that SIMIT was not able to handle the
demands needed. It lacked fail-safe slave support. This is why solution III
(PLC–C/C++) was more carefully examined than most of the other solutions
as a desperate attempt to solve the fail-safe issues.
This shows the problem when using commercial programs: it is hard to
influence the developers to add the support needed for a particular project,
even though they are based within the same company.
The fail-safe problem was solved, if not fully, in an acceptable way, which
made it possible to continue with the project.
As seen in Figure 3.13 the final solution contain two PLC’s, one for the
main program which takes care of most of the systems, while the turbine govern
program PLC contains the regulator of the turbine (i.e. the PID-controllers).
This makes the above decisions of the chosen simulator setup not totaly accurate
since it is done for a setup with just one PLC for the entire turbine control
program; this is no different from using two or even three PLC’s; the reasoning
is still the same.
Solution I II III IV V
Extra PC Yes Yes Yes
Additional
commercial
software Yes Yes
Extra PLC Yes Maybe1
Extra PLC
memory Yes
Interface card Possibly Yes Yes Yes
Tests
Redundancy? Partly No Yes2 Yes2 Yes
Chg. in PLC
program? Maybe Yes
Can it be done
in 20 weeks Uncertain Probably Uncertain Uncertain Probably
Total cost
(KSEK) ∼ 100 ∼ 120 ∼ 15 ∼ 50 ∼ 80
Table 3.7: Quick recap of investment costs for each solution. Notes: 1 A more
powerful PLC might be needed. 2 If implemented.
1
0
SIMIT+Simba Pro
CP
Turbine Govern
PSU
DP
PROFIBUS
S7-414
PROFIBUS
Ethernet
CP
PSU
DP
Main
S7-417
ES
OS
Figure 3.13: Final hardware setup with the turbine PLC’s containing the control
program and the PC containing the turbine simulation program.
32
4 IMPLEMENTING THE SIMULATOR AND

THE MODEL
In order to create a reasonable model to test the gas turbine control system, a
large amount of data was processed. The model that was finally developed in
this thesis is a bit rough; but with a 20 weeks limited development time, fast
decisions and easy solutions, where demanded.
The best way is to use thermodynamics and calculate pressures, tempera-
tures et cetera through equations and complex mathematical expressions and
dependencies; but that approach would require an entire department working
for a few months, thus this option was dropped rather quickly. Thus, another
plan had to be devised to achieve the goal of a reasonably good model.
4.1 Setting up the simulator

Setting up the simulator system with SIMIT, PC’s and PLC’s was seen like an
easy task from the beginning. Though this proved to be more of a challenge
than expected.
Although Simba PRO does support fail-safe DP-slave support in the latest
versions, SIMIT does not. This causes the final simulator to be somewhat crip-
pled, but it works with a few tricks and simple solutions. Full fail-safe support
is not expected until Mars or April of 2005. Until then the simulator cannot
be seen as fully reliable but the overall functionality can be tested without too
much problems.
4.2 Closed and open loop control

Open loop control is when the signal from the PLC’s drives the output of an
analogue signal or a digital signal. The signal can be used for, in the analogue
case positioning of a valve, or in the other case as an open order to an on/off
valve. When the system does not require any input for these actions it is called
open loop control.
Closed loop control requires an input signal as an answer from the process.
This is necessary in delicate situations when it is necessary to closely monitor
certain positions for valves et cetera. The analogue value is sent to the process
just like in the open loop case, but now an input signal is monitored in the PLC
and compared to the output value. In other words the ordered valve position is
checked against the actual valve position. When these are the same everything
is fine. When they differ the regulators of PI or PID type is regulating the
output signal so that the correct response is achieved from the process.
If it is a digital signal the input signal to the PLC is achieved through a
positioning switch. These switches are located at fully open and fully closed
position of the valves. In some cases the digital response from the process also
includes breakers and other electrical equipment.
The model consists of both open loop and closed loop signals. Open loop
signals are straight forward to implement in SIMIT. Closed loop signals on
the other hand takes development time because they are more sensitive to the
process feedback. Thus, the closed loop signals needs more simulation and
analysis when simulating against the control program to ensure that the signals
behave correctly.
4.3 Building HMI 33
4.3 Building HMI

The human machine interface consists of,
• Diagram screens.
• Operator screens.
First off, one need to consider that the simulator should be easy to maintain
and improve. Thus the HMI needs to be easy to overlook and understand.
For this purpose a common graphical user interface for all the systems was
designed to make maintainable and improvement tasks easier, as well as using
it.
Each picture contain a version number, the system name and the authors
of the system. This makes co-operation between more than one engineer easier
since version handling is a major subtask that could take much of the develop-
ment time if not done correctly. And since SIMIT does not contain any easy
concurrent engineering system this is a must. In Figure 4.14 the user interface
of an operator screen can be seen. For a diagram screen see Figure 4.19.
Figure 4.14: The HMI of a turbine system (operator screen).
Another aspect of a well designed user interface is that each signal group
should be well defined and easy to overlook in a quick way for an engineer. This
actually proved to be a problem; how the signals should be grouped. This was
decided on an individual basis for each system. For example, should alarm signal
toggling be implemented in the same system as it is grouped or in a operator
screen where all alarm signals are located. Here, the decision fell on the first
proposal, since each gas turbine system is well defined by Siemens engineers
and going outside the system grouping would prove non intuitive. This is if an
34
engineer which is familiar with the gas turbine system classification scheme at
Siemens would work with the simulator.
Each signal group is defined the same way both in the operator as well as
the diagram screens to get a more intuitive connection between the two. The
goal was to make the entire diagram scheme visible on the screen at the same
time; although this proved to be an impossible task. Thus, the diagram was
divided into pages (a feature which SIMIT support).
In Figure 4.15 a list of how diagram and operator screens are grouped, in
SIMIT, can be seen.
Figure 4.15: Grouping of diagram and operating screens in SIMIT. The different
alphanumeric codes are an internal Siemens scheme for naming different systems
in the turbine.
4.4 The development cycle

A major problem was that the turbine control program was developed simul-
taneously as the simulator program. This created confusion and often resulted
in major changes in the simulator program on a daily basis. At the end of the
development cycle the program had to be verified against the turbine control
program and had to be evaluated against several important criteria. If not ful-
filled the development cycle had to be restarted, and as stated, often with a new
turbine control program with major differences from the old.
A few criteria has to be met for the simulator. These are,
• Real time response.
• Behavior.
• Interface communication.
4.5 A simulation diagram example (calculating heat flow) 35
Real time response connects to the closed-loop problem as explained before.

If the real time response is not correct in SIMIT the turbine will behave in a non
standard way, often causing the turbine control program to fail. This, of course,
connects to the behavior of the turbine. Although, the behavior, includes all of
the modeled signals which affect the simulation of the turbine.
Finally, interface communication have to be checked and verified since each
signal has to reach the destination it is meant to.
A conclusion could thus be that all these properties are closely connected to
each other and, obviously, have to be fulfilled for the simulator to work correctly.
The development cycle can be seen in Figure 4.16.
4.5 A simulation diagram example (calculating heat flow)

It would be impossible, in this thesis, to describe how all the diagram and
operator screens was developed. Thus, an example as seen in Figure 4.19 will
be discussed more precise here to let the reader get a grasp of the development
process.
4.5.1 Using performance data

By using saved data from performance tests, from the Siemens test rig facility for
core engines, a relation between heat flow values and turbine speed was found.
In turn the turbine speed also relates to temperature, pressure and flow. All of
these signals are included in the performance tests, why it is possible to create
a reasonable model of the gas turbine. These values are presented graphically
as trends of signals in the program SCADA Pro, this program is a trend and
monitoring program which is not a part of the SIMATIC suite. By adding all
of the signals to SCADA Pro (see Figure 4.17), reviewing them and talking to
the staff engineers at Siemens and by reading internal documents of the engine
behavior one were able to get an understanding of how the turbine works.
Every line on the picture in Figure 4.17 is a signal, the test run of the turbine
is 2.5h, and by setting the resolution in seconds in SCADA Pro to appropriate
level these signals could be exported as a text file. The data for each line consists
of a register of time and value. The time is stretched over 2.5 hours (which is
the turbine running from start to stop) and the program samples every 2s which
leads to an enormous amount of data which had to be fitted in a polygon block,
in SIMIT, which only had 20 entries. A polygon block is a register where a
certain input value relates to a certain output value. One could say that this is
a transfer function.
Instead of time as one of the parameters another relation had to be used.
The decision was made to use the speed as this corresponds to the heat flow
value as mentioned above. A Matlab program that only uses the most significant
points on the line was used. This can be seen in Figure 4.18.
Because of the way the polygon block works it was sufficient with 20 en-
tries. Between two points a line is interpolated so the curve with the 20 entries
corresponds with a reasonably small error compared to the real curve.
This entire operation was preformed on more than 140 signals. When all
data was processed and all polygons created the next thing to do was to build
the actual model in SIMIT.
36
Start
Data from test

rig facility
Analyze data in
SCADA Pro
Process data in
MATLAB
Analyze system
description
documents
(Updated)
control program
Develop model
from
specifications
Sim . operator
screens
Implement model
in SIMIT
Sim . diagram
screens
Test model
against turbine
PLC
Real time
response
Fills the
Behaviour No
demands?
Interface
communication Yes
Updated
control Yes
program?
No
End
Figure 4.16: Simple development process flowchart of the simulator model.

Figure 4.17: Data from performance tests used when developing the model.
Figure 4.18: The relation between the curve taken from SCADA Pro (blue) and
the polygon curve done with Matlab (red).
38
4.5.2 Heat flow versus speed, temperature and pressure

Because of that it is not possible to obtain the heat flow value directly from the
SIMATIC system another method was used. The heat flow value relates to how
much the gas fuel valves are open which are controlled by the SIMATIC system.
This gave the heat flow value indirectly through the ordered valve position.
Now when the heat flow value is calculated it is possible to set up the rela-
tions between heat flow to speed and all other entities like temperature, pressure
and flow.
4.5.3 The pilot flame

The pilot burner is fed with ignite gas through burner six which can be self
attained from the fuel system. This burner is used for starting the turbine as
well as later when running the turbine. In the beginning only burner 6 is used
to obtain a pilot flame through the ignition gas and a start plug, which ignites
the gas. The pilot flame is later used to ignite the other fuel burners. There
is a closed loop control on the pilot flame. There is no response from a flame
indication transmitter, the ignition gas is stopped and the startup sequence
is stopped. When the pilot flame has ignited the other burners a main flame
indication transmitter is triggered and the fuel system is now up and running.
Burner 6 is in the combustion chamber of the turbine. The other 17 burners
are at this stage not used. When the the pilot flame is indicated as on by the
control system it opens the fuel flow to the other burners.
4.5.4 Necessary adjustments

Until this moment the model is built under the influence that a heat flow is
established. This of course cannot be if the pilot and the main flame have not
been ignited. Therfore, it was also necessary to build program functions that
easily can switch from different operating mode with flame or without flame.
When the sequences are running, the program estimates process values in
order to continue with the next step, this happens both before and after ignition.
Some signals as pressure and temperature level are switched in at some steps to
ensure that the sequence continues. In SIMATIC this is called transition steps,
where certain signals have to be fulfilled before the sequence continues with the
next step. By running the sequences and looking at the transitions (as seen in
Table 2.4 one becomes aware of all the necessary requirements which had to be
included in the model). Other necessary requirements which had to be taken
into account is that a temperature has a delay when cooling off, in resemblance,
as the plate on the stove is turned off. This resulted in several first order time
delay blocks (PT1, Figure 4.19), the function of these block is that the ramp
up/down the value to the given set point in certain time, like a step response.
At some locations it was also necessary to have different ramp speed at different
heat flow values to achieve a working model.
4.5.5 A run with the model

When all sequences are run through, like mentioned in Section 4.5.3, the unit is
in service. Now it is up to the operator to set the speed of the power turbine, if
a max load was set by the operator. By using the model one can simulate that
Figure 4.19: The SIMIT model to calculate the heat flow value.
40
the heat flow value increases as well as the speed of the power turbine. And as
the speed increase the pressures, flows and temperatures also increase.
By using this simulator it is very easy to see how the regulators behave at
start up and switching in between. When reaching the maximum load another
phenomenon has to be taken in account. When the regulators works closely
together the exhaust temperature gets very high at max load. Then the T7L
limiter (Section 2.11.4) in operation, makes sure that the temperature is not
increasing to dangerous levels while NGGL (Section 2.11.2) tries to reach the
set point set by the operator.
Here, the model was too fast in the beginning and the system was unstable.
By adding a first order time delay the model was stabilized.
5 RESULT 41
5 RESULT
5.1 Conclusions and discussion
First of all, all action points and questions at hand was not fulfilled. The authors
had to leave out the implementation of other turbine models; one proved to be
more than enough to be able to handle within the decided time frame. This
could be something for future engineers to work on (see the next section).
To summarize things the positive advantage of the solution developed is,
• The PLC’s are not overloaded since SIMIT is a program running on a

stand-alone PC.
• The communication and load by the PROFIBUS cables are simulated in

a proper way.
• An easy overlook of the simulator can be seen since it is divided into

systems and signal groups. These system and signal groups also follows
the Siemens system of grouping thus making it easier for other engineers
to easily understand the simulator screens.
• The final simulator can be used as a factory acceptance test tool.
• It is more advanced than the current model used.
There are, however, a few negative points,
• The employees have to learn a new tool for simulation.
• SIMIT can not simulate signals of higher resolution than 10ms which could
lead to problems when powering up and down the turbine.
Finally, a test against the control program using the model in SIMIT was
performed. Obviously, at first several problems was encountered, thus the model
had to be adjusted. After some more development a successful start of the
turbine was performed using the simulator.
The involved personnel, on the department where this thesis was developed,
was satisfied with the developed model since it simulates a turbine more accurate
than the current.
Finally, a presentation of the model was done for the Siemens personnel from
the research and development departments to verify that the model worked in
a satisfactory way and to show the SIMIT software which has never been used
at this Siemens facility. This resulted in a discussion on how the model could
be used with for example customer training.
The HMI was also seen as simple which would not require to much “know
how” about control systems which would make it simpler for sales personnel to
demonstrate it to potential customers.
As of February 2005 Siemens has decided to improve the simulator by de-
veloping it on other turbine models. This has resulted in the employment of
another thesis worker which are to examine if this is possible.
Siemens has understood the importance of having such an environment as
this to simulate different test cases and system behavior. Also the customers
have started to demand, more and more, that the systems being sold should
42
be stable and bug free. With this simulator setup the chances of this are much
higher. This, in turn, will lead to lower costs when installing the turbines on
site.
5.2 Future development

The model which has been created works satisfactory as a turbine but some
adjustments must be made to ensure that the model truly behaves like a real
turbine.
Another improvement which should be done is that the model built is just
for the core engine with a simple add-on of load; a compressor. If Siemens wish
to simulate the behavior of a real compressor there are additional things that
have to be taken under consideration such as suction pressure, temperature and
polytrophic efficiency of the compressor. This is not included in the scope of
the model presented in this thesis.
The model also have some problems in the start before reaching 3250rpm
of the power turbine. The entire system is not entirely stable, this is probably
because the temperatures and acceleration of the power turbine is too rapid, in
other words the LLD (loss of load detection, Section 2.11.10) limit is reached
which makes the regulators switch to GDC i.e. the turbine is decelerated, see
Section 2.11.8. Here it would be necessary to recall the data from a real site
with a compressor mounted to further develop the model to act more accurate.
Another problem could be that the actual regulators are set with a too high
gain which in turn gives an unstable behavior. Nevertheless this is not in the
scope of this thesis since the goal was to get a “rough”, initial model, of a
turbine.
To further improve and tweak the model could thus be investigated as an
entire thesis itself.
REFERENCES 43
References
[1] Abb in australia, September 2004. URL http://www.au.abb.
com/global/auabb/auabb500.nsf!OpenDatabase\char’38db% =/
global/auabb/auabb504.nsf\char’38v=DB6\char’38e=us\char’38c=
5C2BD9E042EE7A41% C1256D86001BEF70.
[2] Fieldbus technology, October 2004. URL http://murray.newcastle.edu.
au/users/students/1999/c9518176/fieldbuste% ch.html.
[3] Profibus - profibus & profinet., June 2004. URL http://www.profibus.
com/profibus.html.
[4] Siemens AG. S7-400 and m7-400 programmable controllers
- hardware and installation.
, September 2004. URL http://www.siemens.co.jp/simatic/japan/as/
plc/data/400/424ish\_e.pdf.

Modelling and Simulation of A Gas Turbine: Henrik Klang Andreas Lindholm

Uploaded by

Copyright:

Available Formats

You might also like

Modelling and Simulation of A Gas Turbine: Henrik Klang Andreas Lindholm

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelling and Simulation of A Gas Turbine: Henrik Klang Andreas Lindholm

Uploaded by

Copyright:

Available Formats

Examensarbete

Modelling and simulation of a gas

Department of Science and Technology Institutionen för teknik och naturvetenskap

Modelling and simulation of a gas

Handledare Tomas Strömberg

Institutionen för teknik och naturvetenskap 2005-04-22

Department of Science and Technology

Språk Rapporttyp ISBN

URL för elektronisk version

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –

© Henrik Klang, Andreas Lindholm

Henrik Klang and Andreas Lindholm.

Stockholm and Finspång, February 2005.

Mandatory quotes from (in)famous persons

“Sometimes a scream is better than a thesis.” - Ralph Waldo Emer-

Keywords: Automatic control, fieldbus, gas turbine, modelling, S7, Siemens,

2.12.2 Gas fuel sequence . . . . . . . . . . . . . . . . . . . . . . . 21

3 DECIDING THE SIMULATOR SETUP 25

4 IMPLEMENTING THE SIMULATOR AND THE MODEL 32

1.3 Questions at hand

• What kind of system should be used for the simulator?

• What system is feasible to use concerning cost, training, and implemen-

• In which way should the human machine interface of the simulator be

• How should other turbine models be implemented in the simulator and

1.5 History of the Finspång development site

1.6 The structure of this thesis

2.1 Overview of fieldbus technology

• Design and engineering - Building the networks around well defined

older standards profibus

Table 2.1: Comparison between PROFIBUS and older fieldbus standards

• Installation and commissioning - Since the fieldbus I/O’s can be more

PROFIBUS[3] specifies everything from the medias electrical properties (the

Figure 2.1: Old fieldbus network.

I/O device I/O device

Figure 2.2: Modern fieldbus network.

PROFIBUS-DP[3] is a extension of the PROFIBUS standard which is designed

2.5 The Siemens SIMATIC totally integrated automation

2.6 SIMATIC hardware

2.7 Engineering and operator stations

• Rack (“UR2”) - Where the hardware components are mounted.

2.7.2 DP-slaves explained

2.8 SIMATIC software

• SIMATIC manager - All-in-one control center for the SIMATIC suite

• WinCC - OS and ES station development and usage.

• Hardware config - Configuration of the hardware setup, used in the

• Sequential function chart editor - Program used to build sequences

• NetPro - Program to set up communication between PLC’s and OS.

2.8.1 SIMATIC manager

The manager shows projects currently open, a summary of the hardware

2.8.2 Hardware config

In Figure 2.4 a hardware setup can be seen as defined by the hardware

2.8.3 SFC editor

2.8.4 CFC editor

2.8.6 Fail-safe versus non fail-safe

2.9 The Siemens SIMIT simulation system

2.9.1 SIMBA Pro

x86 Simulator PC with Windows 2000

SIMBA Pro Driver SIMBA Pro PROFIBUS-DP