Report - Høgskolen i Telemark

Project report 2010
Candidates:
Title:
Arome Damian Okpanachi
Emuobosa Ogheneruona Utake
Manjula E.V.P.J
Raghunath Balasubramanian
Ronnie Anseth
Sunday Success Obada
Design of a SCADA system used
on a Four-tank Laboratory Process
Telemark University College
Faculty of Technology
Kjølnes
3914 Porsgrunn
Norway
Lower Degree Programmes – M.Sc. Programmes – Ph.D. Programmes
TF-ver.0.9

Telemark University College
Faculty of Technology
M.Sc. Programme
PROJECT REPORT, COURSE CODE SCE4006
Students:
Thesis title:
Anseth R., Manjula E.V.P.J, Obada S.S, Okpanachi A.D., Raghunath B. and
Utake E.O
Design of SCADA system used on a Four-Tank Laboratory Process
Signatures: . . . . . . . . . . . . . . . . . . ……………………………………. . . . . . . . . . . . . . .
Number of pages: 116
Keywords: SCADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Silverlight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supervisor: sign.: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 nd Supervisor: sign.: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Censor: sign.: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
External partner: sign.: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Availability:
Open
Archive approval (supervisor signature): sign.: . . . . . . . . . . . . . . . . . . . . . . . . Date : . . . . . . . . . . . . .
Abstract:
This project work is about the development of SCADA software which is to be tested on a four-tank laboratory
process. The object oriented analysis, design and programming concept was utilised for the software
development. The star UML tool was used during the analysis and design phase of the software development
cycle. The SCADA software was divided into different modules; control application, database and client
application. The graphical user interface (client) and SCADA database were designed using Microsoft Visio and
the implementation was done using Silverlight 4 which is a web application development tool and SQL server
management studio respectively. The graphical user interface for the control application was implemented using
WPF which is a graphical development system for rendering user interfaces in a windows-based application.
While the application developed using Silverlight can be hosted on a website, that of WPF are basically
deployed as standalone desktop programs which is the case here or hosted as an embedded object in a website.
All associated codes for the control application including the read operation, write operation and control
algorithm were implemented in C#. The access to the database from both the Silverlight and WPF applications
were implemented based on the ADO.NET technology.
WCF is one of the services that Silverlight uses as a communication mechanism with other systems and is an
API in the .NET framework for developing service oriented applications. The WCF RIA service was used in this
project and it builds upon the WCF stack, it provides a means of sharing validation and logic between the client
and the server and also a framework for validation, data access and security which can be shared between
Silverlight and other clients.
The developed software was tested at different phases of development; unit test, integration test and system test
before deployment which was carried out using IIS.
The SCADA software has inbuilt redundancy such that a break in communication between the server (database)
and the control application on the computer in the same location as the four-tank laboratory process will not
affect the control as a back up configuration file is used.
Telemark University College accepts no responsibility for results and conclusions presented in this report.
2

Table of contents
ABSTRACT: ............................................................................................................................................................. 2
PREFACE .............................................................................................................................................................. 6
NOMENCLATURE .............................................................................................................................................. 7
OVERVIEW OF TABLES AND FIGURES....................................................................................................... 9
PART I ................................................................................................................................................................. 12
1 INTRODUCTION ..................................................................................................................................... 13
2 LITERATURE REVIEW ......................................................................................................................... 14
2.1 SCADA SYSTEMS .................................................................................................................................... 14
2.1.1 SCADA server ............................................................................................................................... 14
2.1.2 SCADA client ................................................................................................................................ 16
2.1.3 SCADA Development Environment ............................................................................................... 18
2.1.4 Types of SCADA Systems .............................................................................................................. 19
2.1.5 Alarm system ................................................................................................................................. 23
2.2 SILVERLIGHT ........................................................................................................................................... 26
2.3 WINDOWS PRESENTATION FOUNDATION ................................................................................................. 27
2.4 WEB SERVICES......................................................................................................................................... 27
2.5 ASP.NET ................................................................................................................................................ 28
2.6 WCF SERVICE ......................................................................................................................................... 28
2.6.1 WCF RIA services ......................................................................................................................... 29
2.7 OPC ........................................................................................................................................................ 29
2.8 FOUR-TANK PROCESS .............................................................................................................................. 31
2.8.1 System description ......................................................................................................................... 32
2.8.2 Mathematical Model of the Four Tank Process ............................................................................ 35
2.9 DATABASE SYSTEMS................................................................................................................................ 38
PART II ................................................................................................................................................................ 42
3 ANALYSIS OF SOFTWARE ................................................................................................................... 43
3.1 REQUIREMENTS ....................................................................................................................................... 43
3.2 USE CASES ............................................................................................................................................... 44
3.3 DOMAIN MODEL ...................................................................................................................................... 45
3.4 FULLY DRESSED USE CASE DOCUMENT .................................................................................................... 46
3.5 SYSTEM SEQUENCE DIAGRAM .................................................................................................................. 46
3.6 SEQUENCE DIAGRAM ............................................................................................................................... 46
4 SYSTEM DESIGN .................................................................................................................................... 47
4.1 DESIGN OF SOFTWARE ............................................................................................................................. 47
4.2 GRAPHIC DESIGN OF USER INTERFACE .................................................................................................... 47
4.2.1 Navigation chart ............................................................................................................................ 47
4.2.2 Login page ..................................................................................................................................... 48
4.2.3 Main page ..................................................................................................................................... 48
3

4.2.4 Configuration page ....................................................................................................................... 49
4.2.5 Alarm page .................................................................................................................................... 49
4.2.6 Control application configuration page ........................................................................................ 50
4.2.7 Configure alarm page ................................................................................................................... 52
4.2.8 Configure report page ................................................................................................................... 53
4.2.9 Report page ................................................................................................................................... 54
4.2.10 Monitoring page ....................................................................................................................... 54
4.2.11 Control application .................................................................................................................. 55
4.3 DESIGN OF DATABASE MODEL ................................................................................................................. 56
5 IMPLEMENTATION OF SOFTWARE ................................................................................................. 58
5.1 CONTROL APPLICATION ........................................................................................................................... 58
5.1.1 Configuration files ........................................................................................................................ 58
5.1.2 Initialization .................................................................................................................................. 59
5.1.3 Database communication .............................................................................................................. 61
5.1.4 DAQ communication ..................................................................................................................... 61
5.1.5 Starting the control application .................................................................................................... 63
5.1.6 Control algorithm .......................................................................................................................... 65
5.1.7 Control configuration .................................................................................................................... 66
5.1.8 Stopping the control application ................................................................................................... 67
5.2 SILVERLIGHT APPLICATION ..................................................................................................................... 68
5.2.1 WCF service .................................................................................................................................. 68
5.2.2 Login Page .................................................................................................................................... 69
5.2.3 Main Page ..................................................................................................................................... 70
5.2.4 Monitoring page ............................................................................................................................ 71
5.2.5 Configuration page ....................................................................................................................... 73
5.3 DATABASE IMPLEMENTATION USING MS SQL SERVER 2008 .................................................................. 74
5.4 TESTING .................................................................................................................................................. 74
5.4.1 Unit Test ........................................................................................................................................ 75
5.4.2 Integration test .............................................................................................................................. 76
5.4.3 System test ..................................................................................................................................... 77
PART III .............................................................................................................................................................. 78
6 DEPLOYMENT ........................................................................................................................................ 79
6.1 DATABASE DEPLOYMENT ........................................................................................................................ 79
6.2 CONTROL APPLICATION DEPLOYMENT (WPF) ......................................................................................... 80
6.3 CLIENT APPLICATION DEPLOYMENT (SILVERLIGHT) ................................................................................ 80
7 CONCLUSION AND RECOMMENDATIONS ..................................................................................... 82
REFERENCES .................................................................................................................................................... 84
PART IV .............................................................................................................................................................. 86
APPENDICES ..................................................................................................................................................... 87
APPENDIX A: TASK DESCRIPTION ..................................................................................................................... 87
APPENDIX B: UML DIAGRAMS AND FDUCD .................................................................................................... 90
4

B1: System Sequence Diagrams (SSD)........................................................................................................ 90
B2: Fully Dressed Use Case Document ...................................................................................................... 95
B3: Sequence Diagram ................................................................................................................................ 99
B4: Class Diagram .................................................................................................................................... 106
B5: Object Diagram .................................................................................................................................. 107
APPENDIX C: DATABASE SCRIPT ..................................................................................................................... 108
APPENDIX D: PROJECT CODE AND DEPLOYMENT FILES. .................................................................................. 116
5

Preface
This group project work is done as a part of the requirements for the award of the Master's
degree in Systems and Control Engineering at the Telemark University College (Høgskolen i
Telemark, Porsgrunn) in Norway. The report is written based on the requirements for the
development of a SCADA system for control of a tank laboratory system.
The entire work has been carried out on the campus of Telemark University College (HiT).
Some of the necessary technical information and data needed have been obtained from the
previous bachelor thesis report presented for the designed four-tank laboratory process and
also the master thesis of Victor Okpanachi Ademu. The entire implementation has been done
using Silverlight 4 web application development tool of the MS Visual studio Ultimate 2010
and using C# programming language as well as the WPF application development tool of the
MS Visual studio Ultimate 2010.
It is imperative that the reader should have some basic knowledge of object oriented analysis
and design, C# programming, the use of UML, Silverlight, SQL and WPF in order to fully
understand this report.
We wish to convey our sincere gratitude to Hans-Petter Halvorsen (MSc) for his guidance and
supervision in implementation of this task all the way through.
He has also consistently been able to correct us and provide solutions whenever we faced
troubles in letting us know what next to do.
We also would like to express our gratitude to Associate Professor Nils-Olav Skeie (PhD) for
guiding us in the analysis and design of the software.
Porsgrunn, 22nd, November 2010
Arome Damian Okpanachi
Emuobosa Ogheneruona Utake
Manjula E.V.P.J
Raghunath Balasubramanian
Ronnie Anseth
Sunday Success Obada
6

Nomenclature
This section gives a listing of all the abbreviations used in this report.
AC
API
CORBA
COM
DAQ
DBMS
DC
DCOM
DCS
DDE
DLL
FDUCD
FURPS+
GRASP
GUI
HMI
HTML
IIS
IIOP
IT
LAN
MAX
MIMO
MS
NI
ODBC
OLE
OOA
OPC
ORB
Alternating Current
Application Programming Interface
Common Object Request Broker Architecture
Component Object Model
Data Acquisition
Database Management System
Direct Current
Distributed Component Object Model
Distributed Control System
Dynamic Data Exchange
Dynamic Link Library
Fully Dressed Use Case Document
Functionality-Usability-Reliability-Performance-Supportability-
Design Limitation
General Responsibility Assignment Software Patterns
Graphical User Interface
Human Machine Interface
HyperText Markup Language
Internet Information Services
Internet Inter-ORB Protocol
Information Technology
Local Area Network
Measurement & Automation Explorer
Multiple-input and Multiple-output
Microsoft
National Instruments
Open Database Connectivity
Object Linking and Embedding
Object Oriented Analysis
OLE for Process Control
Object Request Broker
7

OS
PAC
PID
PLC
RAID
RIA
RMI
RTDB
RTU
SCADA
SOAP
SSD
SQL
TCP/IP
UI
UML
VB
WAN
WCF
WPF
XAML
XML
Operating System
Programmable Automation Controller
Proportional Integral Derivative
Programmable Logic Controller
Redundant Array of Independent Disks
Rich Internet Application
Remote Method Invocation
Real-Time Database
Remote Terminal Unit
Supervisory Control and Data Acquisition
Simple Object Access Protocol
System Sequence Diagram
Sequential Query Language
Transmission Control Protocol/Internet Protocol
User Interface
Unified Modeling Language
Visual Basic
Wide Area Network
Windows Communication Foundation
Windows Presentation Foundation
Extensible Application Markup Language
Extensible Markup Language
8

Overview of tables and figures
Figure 2-1: Typical Software Architecture of a SCADA system [3]...................................... 15
Figure 2-2: Schematic of a distributed SCADA system ......................................................... 20
Figure 2-3: Schematic of a networked SCADA System ........................................................ 21
Figure 2-4: The main functions of an alarm system [8] ......................................................... 25
Figure 2-5: Alarm state description [1] ................................................................................. 26
Figure 2-6: Left side shows the application when loaded and the right side shows the
application when the button “Click me” is clicked ................................................................ 27
Figure 2-7: The basic structure of a Web Service [14] .......................................................... 28
Figure 2-8: A general SCADA software application with a lot of different protocols between
software modules [1] ............................................................................................................ 30
Figure 2-9: SCADA Application using OPC as protocol for interconnection [1]................... 31
Figure 2-10: Four-tank laboratory process equipment ........................................................... 32
Figure 2-11: Diagrammatic representation of the four-tank process ...................................... 33
Figure 2-12: Signal flow and scaling from sensor to LabVIEW application .......................... 34
Figure 2-13: NI USB-6008 DAQ device from National Instruments ..................................... 35
Figure 2-14: Overview of the control system and the process................................................ 37
Figure 2-15: Data Hierarchy Schema, Records and data in a database [1] ............................. 38
Figure 2-16: Example of SCADA system with database [1].................................................. 39
Figure 2-17: Diagram of real time database and applications for data access [22] ................. 41
Figure 3-1: Analysis Phase of the SCADA software development [1]................................... 43
Figure 3-2: Use case diagram of the SCADA system ............................................................ 45
Figure 3-3: Domain Model of the SCADA system ................................................................ 46
Figure 4-1: Analysis and Design phases of the SCADA software development [1] ............... 47
Figure 4-2: Chart showing the navigation flow ..................................................................... 47
Figure 4-3: Design of the Login page of the SCADA application .......................................... 48
Figure 4-4: Design of the main page of the SCADA application ........................................... 48
Figure 4-5: Design of the configuration page of the SCADA application .............................. 49
Figure 4-6: Design of the alarm page of the SCADA application [1]..................................... 50
Figure 4-7: Design of the control application configuration page of the SCADA application 51
Figure 4-8: Design of the configure alarm page of the SCADA application .......................... 52
Figure 4-9: Design of the configure report page of the SCADA system ................................ 53
Figure 4-10: Design of the report page of the SCADA system .............................................. 54
Figure 4-11: Design of the monitoring page of the SCADA system ...................................... 55
9

Figure 4-12 Design of the control application ....................................................................... 56
Figure 4-13: Database model adopted for the SCADA system .............................................. 57
Figure 5-1: The SQL configuration file DAQcontrolApp.exe.config content. ....................... 58
Figure 5-2: The configuration backup file ConfigBackup.txt content. ................................... 59
Figure 5-3: The control application UI when initialized and ready to run. ............................. 60
Figure 5-4: The control application UI if the DAQ connection fails. ..................................... 61
Figure 5-5: Running control application................................................................................ 64
Figure 5-6: Controller configuration child window with the different tabs. ........................... 67
Figure 5-7: Login page for the Silverlight application. .......................................................... 69
Figure 5-8: Login page if login fails (wrong username or password). .................................... 70
Figure 5-9: Main SCADA page when login is successful as Administrator. .......................... 70
Figure 5-10: Main SCADA page when login is successful as Operator. ................................ 71
Figure 5-11: Monitoring page for the SCADA system. ......................................................... 72
Figure 5-12: Setpoint configuration child window. ............................................................... 73
Figure 5-13: Configuration page of the SCADA system. ...................................................... 73
Figure 5-14 : Control configuration child window in the Silverlight application. .................. 74
Figure 5-15: Unit test procedure for SCADA system ............................................................ 75
Figure 5-16: Integration test procedure for SCADA system .................................................. 76
Figure 5-17: System test procedure for SCADA system ........................................................ 77
Figure 6-1: Overview of SCADA system .............................................................................. 79
Figure B. 1: SSD of the Read sensors usecase ....................................................................... 90
Figure B. 2: SSD of the Control pumps usecase .................................................................... 90
Figure B. 3: SSD of the Control Algorithm usecase .............................................................. 91
Figure B. 4: SSD of the Alarm system usecase ..................................................................... 92
Figure B. 5: SSD of the Configuration usecase ..................................................................... 93
Figure B. 6: SSD of the SQL usecase.................................................................................... 93
Figure B. 7: SSD of the Reporting system usecase ................................................................ 94
Figure B. 8: SSD of the Monitor system usecase................................................................... 94
Figure B. 9: Sequence diagram of the Read sensor usecase ................................................... 99
Figure B. 10: Sequence diagram of the control pump usecase ............................................. 100
Figure B. 11: Sequence diagram of the Control Algorithm usecase ..................................... 101
Figure B. 12: Sequence diagram of the Configuration usecase ............................................ 102
Figure B. 13: Sequence diagram of the Alarm system usecase ............................................ 103
10

Figure B. 14: Sequence diagram of the Monitor system usecase ......................................... 104
Figure B. 15: Sequence diagram of the Report system usecase ........................................... 105
Figure B. 16: Class diagram of the SCADA software application ....................................... 106
Figure B. 17: Object diagram of the SCADA software application ...................................... 107
Table 2-1: Overview of states, parameters and nominal values [21] ...................................... 36
Table 5-1: DAQ task descriptions ......................................................................................... 62
Table 5-2: WCF read service options .................................................................................... 68
Table B. 1: FDUCD of Control Algorithm use case .............................................................. 95
Table B. 2: FDUCD of Configuration Use case .................................................................... 96
Table B. 3: FDUCD of Alarm System .................................................................................. 96
Table B. 4: FDUCD of SQL ................................................................................................. 97
Table B. 5: FDUCD of the Report system ............................................................................. 97
Table B. 6: FDUCD of the Monitor System .......................................................................... 98
11

PART I
12

1 INTRODUCTION
SCADA systems are widely used in Industrial processes among which are manufacturing,
production, power generation, refining and a host of others. The development of SCADA
systems over time have taken advantage of computing power of computers, information
technology and web technology such as AJAX, WPF, Silverlight. Hence it is imperative for
students to improve their knowledge in the present day solutions obtainable in the industry.
As a result, the SCADA system developed for a four tank laboratory process in this project
will be used in the student laboratory work within courses such as Control systems with
implementation, Industrial IT etc.
The goal of this project is to design a modern SCADA system and implement a prototype
with the latest technology available and the task description is shown in appendix A. It
involves applying project management techniques, such as dealing with requirements, system
development, testing, deployment and documentation.
The prototype shall be tested on a four-tank laboratory process. In this project star UML was
used for analysis, Microsoft Visio for the user interface design, WPF and Silverlight for
graphics development (client application), C# for the programming and the database was
developed in the SQL server management studio.
The implementation of the design was done based on some assumptions that the four-tank
process is operated with no disturbance, implying that the valves are fully open, to keep the
control simple since no advance control algorithm was implemented. The developed
prototype is not a full representation of the design but a functional miniature of the full scale
design; this is as a result of the time constraints for the project. Also, there were some
resource limitations as a real-time database would have been more appropriate for the
SCADA but a relational database was utilised.
The report has four parts (I, II, III and IV), Part I consist of two chapters (1 and 2). The
introduction, the background and the project goal are presented in Chapter 1 and the SCADA
system literature study is discussed in chapter 2.
Part II consists of three chapters (3, 4 and 5). Analysis of SCADA system software using the
star UML tool is presented in Chapter 3. System design of SCADA system software modules
using Microsoft Visio is presented in Chapter 4 while the testing and implementation of the
SCADA system software modules using WPF, SQL management Server studio and
Silverlight is presented in Chapter 5.
Part III consists of two chapters (6 and 7). The deployment and documentation of the SCADA
software is presented chapter 6 and Chapter 7 contains conclusion and recommendation for
further work. Part III also contains the references. Part IV contains the appendices.
13

2 LITERATURE REVIEW
This focus of this chapter is on the literature survey of SCADA systems and its various
subsystems as well as the various parts that relate to it directly and indirectly like the fourtank
process, web services, WCF services, WCF RIA services, Silverlight, WPF, ASP.NET
OPC and others.
2.1 SCADA systems
According to [1], a SCADA system is a software application (module) running on an
industrial computer, often with an alarm system, a database and a UI used to monitor and
control a process. The operating system on which the SCADA server is running on is usually
a real time operating system, a typical SCADA software architecture is shown in Figure 2-1.
This process can be infrastructure, facility, telecommunications or industrial processes
(Industrial processes include production, refining, manufacturing, fabrication, and power
generation which may run in batch, continuous, discrete or repetitive modes).
This system involves transferring data between a central computer (host) and a number of
RTU 1 s/PLC 2 s via network communication.
2.1.1 SCADA server
2.1.1.1 Data access
The Data server pulls data from the controllers (RTU, PLC and PAC) at a user defined rate,
polling rates may be different for different parameters. In the communication between the
controllers and the data server the controller is the owner of the data and so the server has to
poll the associated controllers whenever it needs information. The requested parameter is
passed from the controller to the data server; which is time stamped by the controller.
2.1.1.2 Interfaces
OPC is an open standard interface between different data sources, such as programmable
logic controllers (PLCs), remote terminal units (RTUs), distributed control system (DCS) and
sensors on a factory floor to HMI/SCADA applications, application tools, and databases.
With OPC, device-side server and application software can communicate without duplication
of device driver development and it provides support for hardware feature changes [2]. The
1 Remote Terminal Unit
2 Programmable Logic Controller
14

OPC Foundation defines the standards that allow any client to access any OPC compatible
device.
Figure 2-1: Typical Software Architecture of a SCADA system [3]
ODBC is an acronym for Open Database Connectivity it provides a standard software
interface for accessing database management systems (DBMS). ODBC is designed to be
independent of programming languages, database systems, and operating systems. Thus, any
application can use ODBC to query data from a database regardless of the platform it is on or
the DBMS it uses. As presented in [1], ODBC accomplishes this by using a middle layer
(database driver) as a translation layer between the application and the DBMS as shown in
Figure 2-1. Hence, the application and the DBMS must be ODBC compliant i.e. the
application should have the capability of sending out ODBC commands while the DBMS
15

should have the capability of replying accordingly [1]. The library of API 1 s supporting C,
C++, visual basic (VB), and C# should be able to access the real time database, logs and
archives. Dynamic Data Exchange allows for visualization of data dynamically in an EXCEL
spreadsheet.
2.1.1.3 Database
The configuration data are stored in a database that is logically centralised and physically
distributed which may be any database model. The RTDB 2 resides in the memory of the Host
(SCADA Server) and is a type of time series database while the historical (archive) data may
be stored in a relational database. The application interfaces with these databases via ODBC
as shown in Figure 2-1.
2.1.1.4 Scalability and redundancy
Scalability is a that required property of a system, a network, or a process, which shows its
capacity to either be extended or handle increasing volumes of work in an elegant manner [4].
With respect to the SCADA system it can be said that it is scalable because it allows for
extension like adding specialized servers like the Alarm handling system. Scalability is
achieved by accommodating multiple servers connected to different controllers (PAC, PLC
and DCS). Each data server has its own configuration database and RTDB which is
responsible for handling a segment of the plant.
Redundancy is the replication of the significant parts of the system with an intention of
increasing the reliability of the system, typically in cases of backup or failsafe [5]. The
SCADA system has built-in software redundancy at the server level, information duplication
like in the storage devices (RAID 3 /backup) and communication duplication is implemented in
both software and hardware to improve reliability.
2.1.2 SCADA client
2.1.2.1 Communication
The communication model adopted between server and client may be any of the following;
• OPC protocol
• TCP/IP protocol
Both of which support the server/client model and publisher/subscriber model see Figure 2-1.
1 Application Programming Interface
2 Real Time Database
3 Redundant Array of Independent Disks
16

2.1.2.2 Human Machine Interface
The HMI may be multiple screens which are clients to the graphic server; the HMI contains
graphical objects with links to the process variables which mimics the plant in a way a user
can monitor the plant and has controls which allows the user to send commands from the
screen to control the plant. Standard windows editing are associated features of the HMI,
zooming, resizing, scrolling and links may be created between pages for easy navigation and
this must be kept simple.
2.1.2.3 Trending
This feature of a client allows parameters to be observed over time, the parameter may be predefined
or can be defined online; multiple parameters may be trended at a time which may be
represented in a chart. Real time and historical trending 1 is possible and parameter values
based on the cursor position is displayed.
The trending feature is provided as a separate module with integrated statistical analysis tools
or graphical objects (Active X) which may be embedded into the HMI.
2.1.2.4 Alarm Handling
According to [3], alarm handling is based on limits and status checks. The alarm system is
integrated in the SCADA system which carries out more complicated expressions (arithmetic
and logic), it can be developed by creating a derived parameter on which status or limit
checks are performed. The alarms are centrally handled in one place in the system meaning
the alarm information exists only in one part of the system and the same information is
propagated to all other parts of the system. Details of the alarm system can be found in section
2.1.5.
2.1.2.5 Logging and Archiving
Logging refers to medium term storage of data to the disk and archiving refers to the long
term storage of data to the disk or a permanent storage device. As presented in [3], logging is
done on a cyclic bases implying that once a certain predefined period or size is reached the
data is overwritten. Log files are transferred to the archive as soon as the predefined limit has
been attained depending on the procedure adopted for archiving which could be time based or
size based. A relational database may be used for archiving purposes. As shown in Figure
2-1, the types of data that are logged are process data, historical data and alarm data.
1 Historical trending is possible for only archived parameter(s)
17

2.1.2.6 Report generation
Reports are generated using SQL 1 queries to the archives, log or RTDB. Software
applications exist to automatically print and archive reports. A report consists of information
presented in a tabular form which may contain statistical charts.
2.1.3 SCADA Development Environment
The development environment allows for the development of graphics which are then linked
to the process parameters in order to give a dynamic graphical representation of the real
process.
As shown in Figure 2-1, an export and import feature is available in the SCADA development
environment, this allows large numbers of parameters to be configured using more efficient
editors like EXCEL and the data is imported into the configuration database. Online
modifications to the configuration database and the graphics are possible but based on the
access level of the user.
Based on [3], it is an environment which allows the user to add to the functionality of the
interface, manipulate files, perform complex mathematical and string operations and to
construct simple control sequences using logical decisions. It is shown in [3] that it may also
be used in conjunction with event driven, cyclic or scheduled actions to further increase the
capability of the application.
Some development tools shown in Figure 2-1 are
• Graphics editor with standard drawing tools, in this environment is possible to import
picture of different format and using predefined symbols from object and symbol
library these objects and symbols are connected to process parameter and their
attributes becomes dynamic with the changing process variable.
• A database configuration tool, mostly as parameter templates, is possible to import or
export files to be edited in ASCII editor or Excel
• Scripting language and API supporting different programming language like C, C++,
VB and C#.
• Tool kit to develop drivers that are not supported by the SCADA application.
The SCADA system consists of the following subsystems, namely
1. Field Equipment: One or more field devices usually, RTUs/ PLCs, DCS 1 , or PAC 2 )
which interface to sensors, valve actuators etc in the process, converting sensor signals
to digital data and sending digital data to the supervisory system see Figure 2-1.
1 Sequential Query Language
18

2. Communications infrastructure: This is used as a medium to transfer data between the
field equipment and the supervisory system. It could be telephone, satellite, cable,
radio or a combination of this etc.
3. Supervisory Station: These are supervisory (computer) system acquiring data on the
process and based on the acquired data controlled the process. These are the servers
and software responsible for the communication with the field equipment and then to
the HMI3 software running on the operator’s workstation or anywhere else as shown
in Figure 2-1. In smaller SCADA systems, the station may be composed of a single
PC but in larger systems, the supervisory station could comprise of multiple servers,
distributed software applications running on several computers concurrently.
4. HMI is the means through which the process data is presented to the human operator
and through this, the human operator monitors and controls the process. This
application acts as a client.
5. An integrated alarm system.
A SCADA system must therefore, consist of different software module, for example; a
monitoring module to get the information from the process and a control module to ’write’
information back to the process [1].
2.1.4 Types of SCADA Systems
SCADA systems have evolved in parallel with the sophistication of modern computers and
communication technologies leading to three generations of SCADA architectures namely
• Monolithic SCADA Systems – These are also known as the first Generation SCADA
system. In the first generation, the computing was done by mainframe computers as
networks did not exist at that time as a result the SCADA systems were independent
(stand alone) systems with no connectivity to other systems.
1 Distributed Computer System
2 Programmable Automation Controller
3 Human Machine Interface
19

The Monolithic SCADA system functions were limited to monitoring sensors with
little control exercise and flagging any operations which exceeded programmed alarm
levels. These systems were all vendor-proprietary software and are usually limited to
a single facility. The SCADA software and hardware from one vendor was rarely
usable in another vendor's SCADA system [6].
• Distributed SCADA Systems – These are also known as second Generation SCADA
system. These systems shared control functions across multiple computers (distributed
systems) which were connected through a LAN 1 and information was shared in real
time. In this architecture, each station was responsible for a particular control task or
group of tasks (in addition to giving operators alert for tripped alarm levels or possible
problems) depending on the computing power needed for such tasks. So the cost of
each station was significantly lower than that used in the first generation, although the
network protocols used were still proprietary which led to security problems and lack
of flexibility as only one vendor’s equipment had to be used. A typical representation
of a distributed SCADA system is shown in Figure 2-2.
Figure 2-2: Schematic of a distributed SCADA system
• Networked SCADA Systems – These are also known as third Generation SCADA
Systems. They are the generation of SCADA systems in use today, having an open
1 Local Area Network
20

system architecture (not vendor dependent) utilizing open standards and protocols,
thus the functionality can be distributed across a WAN 1 rather than a LAN. This
architecture also allows for mixing of different vendor’s equipment.
Earlier SCADA systems primarily use vendor-proprietary software and sometimes
hardware but current SCADA systems are based on more general use software. The
hardware tends to be more interchangeable as PLC and other sub-unit vendors have
standardized communications and other protocols to allow the user to choose the best
component for their needs rather than being tied to one vendor's line of products.
Networked SCADA system has high security risk since it is connected to the internet
unlike the earlier SCADA systems that were limited to single building or sometimes
single site networks [6]. A typical representation of a distributed SCADA system is
shown in Figure 2-3.
Figure 2-3: Schematic of a networked SCADA System
1 Wide Area Network
21

2.1.4.1 Tag-based systems
Usually the development of data access, scripting, alarming and data analysis is based on the
concept of tags 1 . This approach may be simple but it is based on an environment that uses a
flat namespace which is a disadvantage as individual elements cannot be organized into more
intelligent structures with inbuilt interdependencies and associations [7].
When one wants to make a global change to a tag database, it is typically done externally to
the development environment either as a text file or in other tools such as Microsoft excel,
Microsoft access etc and then it is re-imported into the application.
2.1.4.2 Object-Based Systems
The main concept behind object based 2 systems has its roots from the object oriented
architecture which originated from the information technology world [7]. The main advantage
of this architecture was that it provided tools that would ease developers from repetitive and
monotonous program tasks which are susceptible to errors while at the same time allowing
reuse through the development of common components [7].
So for example, a valve class could be defined and all the generic properties of valves would
be defined in this class and every time a new valve needs to be added that has some different
functionality, it could then inherit the general properties from its parent valve class
considering the fact that it is still a valve and the properties that determines its mode of
operation could be defined afterwards. This method has numerous advantages including but
not restricted to reducing the configuration time of various components of the entire system,
reduction in configuration errors 3 etc.
It is important to note that this concept is not so easy to implement for industrial systems as is
the case for IT systems [7].
In a nutshell, it can be said that the tag based system adopts a physical approach in which
devices are represented as tags while the component object based systems adopts a logical
approach in which devices are represented with logical constructs [7].
As the industrial applications are increasing in size, new SCADA variants are now being
designed to handle devices and even entire systems as full entities (classes) that encapsulate
all their specific attributes and functionality as presented in [3].
1 Input/Output information point
2 Also called component based systems
3 Once the properties of the main valve class have been certified to be okay, then we are certain that every new
valve that will inherit properties from this parent valve is as good as certified except for some instances which
have to do with specific functionality.
22

As far as new technologies are concerned, the SCADA products are now adopting:
• Web technology, ActiveX, Java, Silverlight, WPF, ASP.NET etc.
• With the development of the OPC standard, internal communications between the
various software modules in the SCADA application is much easier and it eliminates
the need for multiple driver development [1].
2.1.5 Alarm system
The alarm system monitors the states of the process and gives a warning or an alarm as the
case may be when there is an abnormal condition in the system. An alarm system is a system
that monitors the process and gives an indication when an abnormal or predefined condition is
met [1].
The alarm system is responsible for the warnings and alarms in a SCADA system and it
contains different alarms and warnings like [1];
• Timeout – loss of communication with a field device or other devices after a specific
period of time.
• Out of range alarm – the output signal from the sensor or transmitter is outside the
valid range for example a 25mA for a 4 – 20mA sensor signal will give such a warning.
• Low-Low (LL) High-High (HH) alarm – a critical alarm condition
• Low or High alarm – a less severe alarm condition but requires an action from the
operator.
• Difference alarm – it can be either a critical or not so critical alarm condition. It
usually occurs when there is large difference in the outputs of two or more sensors that
are measuring the same process variable in a competitive sensor configuration.
• I/O device error
• System device error
The colour red should always be used for an alarm indication, the colour green is always used
for a normal condition in the system while the colours yellow, orange and blue can be used
for sub functions in an alarm system but this depends on the alarm philosophy adopted by the
company [1]. The response time of an alarm system should not exceed two seconds,
preferably one second [1].
There are various kinds of alarm systems namely;
• Stand-alone system
• Integrated system
• Distributed system
The stand-alone system comprises of the input devices (sensors), the alarm system, and the
output devices (actuators) for giving the warnings and alarms. In the integrated alarm system,
the alarm system is an integral part of the complete monitoring and control system. In the
23

distributed alarm system, the alarm system is integrated into several monitoring and control
systems.
2.1.5.1 Alarm Types
Alarms are usually generated in the SCADA system [1] and there are various types of alarms
namely [8]
• Basic alarms – generated by detecting deviations on single process measurements or
single pieces of equipment.
• Aggregated alarms – generated by combining the state of a number of basic alarms
that together describe the state of a process system or sub-system more precisely than
a single alarm.
• Model-based alarms – generated based on online simulations by mathematical models
of parts of the process.
• Key alarms – selection of important alarms presented in a way that makes them
available and usable even during alarm overloads. All important safety-related alarms
must be defined as key alarms, although other alarms may be included if necessary.
2.1.5.2 Functions of the Alarm System
The alarms are generated in the SCADA system due to predefined system limits, process
dynamics etc, the main functions of the alarm system illustrated in Figure 2-4 are [8];
• Signal filtering – processing of the raw input signals to the alarm system so as to
remove the noise and other unwanted information for the alarm system such as small
random oscillations.
• Alarm generation – comparison of the input signal with the system limits or checking
the status of the process.
• Alarm filtering – preventing an alarm signal from being available to the operator in
any part of the system (enable/disable alarms).
• Alarm suppression – preventing an alarm from being presented in the main alarm
displays e.g. overview displays, but the alarm is still available in the system at a more
detailed level.
• Alarm shelving is a facility for manually removing an alarm from the main list and
placing it on a shelve list, temporarily preventing the alarm from re-occurring on the
main list until it is removed from the shelf. Shelving will normally be controlled by
the operator, and is intended as a “last resort” for handling irrelevant nuisance alarms
that have not been caught by signal filtering or alarm suppression mechanisms.
24

Figure 2-4: The main functions of an alarm system [8]
2.1.5.3 Alarm states
An alarm will have three different states namely [1];
• Passive alarms – No Alarm, the condition is within the normal operating range. Here,
no alarm is generated in the alarm system.
• Active alarms – the condition has exceeded an alarm boundary and the alarm is
present in the alarm system until it is acknowledged by the operator. The configuration
is such that there will be some blinking indicators and/or horns.
• Acknowledged alarms – this is an active alarm that has been acknowledged by an
operator. The acknowledged alarm will be passive when the condition is within the
normal operating range and the alarm will be present in the alarm system. The
configuration is such that the indicators will be steady (no blinking).
The diagram in Figure 2-5 shows the various alarms states with the alarm limit defined at a
value of 17, the alarm becomes active at time 40s and is acknowledged at time 50s as
indicated by the circle. The alarm becomes passive at time 78s due to the deadband 1 present.
1 A deadband is an area of a signal range where no action occurs i.e. the system is dead.
25

20
Dead Band
Active Alarm
Acknowledged
Alarm
15
10
Value
5
Passive Alarm
0
-5
0 10 20 30 40 50 60 70 80 90 100
time [s]
Figure 2-5: Alarm state description [1]
2.2 Silverlight
Silverlight is a .NET based development platform for creating applications for the Web,
desktop, and mobile devices. Based on [9] and [10], Silverlight is a runtime that runs on the
client machine and sits between the user and the server and integrates multimedia, graphics,
animations and interactivity into a single runtime environment, these applications are often
referred to as Rich Internet Applications (RIAs). As a free plug-in, Silverlight is compatible
across multiple browsers, devices and operating systems and is currently supported by all
major browsers on both Mac OS X and Windows (solution for Linux exists, but not directly
supported) [11].
Silverlight applications are created with Extensible Application Mark-up Language (XAML)
and .NET programming languages (C#, VB etc.). XAML is an XML-based language that has
some similarity to HTML, and is used to design the user interface of .NET Framework
applications. The look of an application can be created without any code in C# or VB,
however, C# and VB is used to specify the UI’s behaviour (XAML separates the UI definition
from the run-time logic by using code-behind files), an example of this is shown below.
XAML code that creates a button with the label “Click me” and an empty textbox on the UI:

In order to define the button behaviour when it is clicked, a code can be written in the
button’s click event in C#:
private void button1_Click(object sender, RoutedEventArgs e)
{
textBox1.Text = "Hello world";
}
This example shows how XAML can create a simple UI and how C# is used to specify the UI
behaviour, the result is shown in Figure 2-6.
Figure 2-6: Left side shows the application when loaded and the right side shows the
application when the button “Click me” is clicked
The two most common tools for creating a Silverlight application are Visual Studio and
Expression Blend. Visual Studio is used to write, compile, debug programs and create simple
user interfaces. Expression Blend is a design tool used to create more advanced user
interfaces using visual tools that generates the associated XAML code and is a part of
Expression Studio. Expression Studio is not strictly needed to create an application, but is a
great tool for customizing the UI (change control layouts, create animations etc.).
2.3 Windows Presentation Foundation
As presented in [12] and [13], WPF is a graphical development system for rendering user
interfaces in a windows-based application by offering great flexibility on how to layout and
interact with an application. WPF utilises XAML, which is an extension of XML, to define
and link various UI elements and can be deployed as standalone desktop programs, or hosted
as an embedded object in a website [12].
2.4 Web services
As presented in [14], web services are a general model that are used for developing
applications that support communication over the internet and are not restricted to any
operation system in terms of implementation. They are simply web APIs that can be accessed
over a network (internet) and executed on a remote system hosting the called services [15].
27

They take advantage of component-based development using models like DCOM, RMI and
CORBA’s Internet Inter-ORB Protocol (IIOP) which all depend on object model-specific
protocols [14].
Web services develop these models by connecting with SOAP (Simple Object Access
Protocol) and XML to eliminate the barrier introduced by the object model-specific protocol
[14]. The basic structure of a Web Service is shown in Figure 2-7.
LOCATION A
LOCATION B
SOAP over HTTP
SOAP over HTTP
INTERNET
USER
XML
XML
WEBS ERVICE
Figure 2-7: The basic structure of a Web Service [14]
According to [14], SOAP calls are remote function calls that call up method executions on
Web Service components at location B, the output is then represented as XML and sent back
to the user at location A.
2.5 ASP.NET
ASP.NET is a web application that allows users to program dynamic web pages, web
applications and web services [16].
2.6 WCF service
The three main communication procedures as presented in [10] with other systems that
Silverlight provides are services via
• WCF
• Direct HTTP communication via the ‘HttpWebRequest’ and ‘WebClient’ classes and
• Raw communication using sockets
However, the focus will be on WCF due to the fact that it was the communication procedure
that was adopted in this project.
As presented in [17] and [18], WCF is an API in the .NET framework for developing
connected, service-oriented applications. By using WCF, data can be sent asynchronously
from one service endpoint to another [17]. Based on [17], a service endpoint can either be a
28

service hosted in an application or it can be part of a constantly accessible service hosted by
IIS while an endpoint can be a client of a service that calls data from a service endpoint.
2.6.1 WCF RIA services
Based on [19], WCF RIA Services is an enhancement to WCF as it builds upon the WCF
stack; it offers a means of sharing validation and logic between the client and the server as
well as a basis for validation, data access, and security which can be shared between
Silverlight and other clients.
2.7 OPC
OPC is ’open connectivity’ via ’open standards’ [20]. OPC is an open connectivity in
industrial automation and the enterprise systems that are supported in the industry.
Interoperability is guaranteed through the creation and maintenance of open standards
specifications. OPC is a series of standard specifications and it was originally based on
Microsoft's OLE COM and DCOM technologies, the specification defined a standard set of
objects, interfaces and methods for use in process control and manufacturing automation
applications to facilitate interoperability [20]. The COM/DCOM technologies provided the
framework for software products to be developed.
As presented in [20], the OPC specifications are:
• OPC Data Access (DA)
• OPC Alarm and Events (AE)
• OPC Batch
• OPC Data eXchange
• OPC Historical Data Access
• OPC Security OPC
• XML-DA OPC
• OPC Commands
• OPC Complex Data
• Unified Architecture (UA)
Based on [1], the most used standards in the process industry are:
• OPC Data Access (OPC DA) - Provides access to real-time, continually changing
data, used to move real-time data from PLCs, DCSs, and other control devices to
HMIs and other display clients, also used for computing and estimating values and
writing values.
• OPC Alarm and Events (OPC AE) - Provides alarm and event notifications on demand
(in contrast to the continuous data flow of Data Access) [20]. These include process
29

alarms, operator actions, informational messages, reporting and tracking/auditing
messages.
• OPC Historical Data (OPC HDA) - Provides access to data already stored, from a
simple serial data logging system to a complex SCADA system, historical archives
can be retrieved in a uniform manner [20].
As presented in [1], a typical SCADA application using the OPC protocol is shown Figure
2-9, the purpose of OPC is to define a common interface that is developed once and then
reused by the different layers of the SCADA application. The OPC server provides an
interface for software packages to access data from process devices such as PLC, DCS and
RTU etc. Then Figure 2-8 shows a SCADA application using different protocols between
software modules. This is a classical SCADA interconnection of different software modules
where a custom interface or driver for an individual software module is developed for
interfacing with other software modules.
Figure 2-8: A general SCADA software application with a lot of different protocols between
software modules [1]
30

Figure 2-9: SCADA Application using OPC as protocol for interconnection [1]
2.8 Four-tank process
The four-tank process model consists of four interconnected cylindrical tanks, two pumps,
two valves and two level sensors which are connected to the lower tanks.
The four cylindrical tanks are mounted vertically on a frame in a two by two symmetric
pattern as shown in Figure 2-10. Each tank has a 20 cm height and 6 cm inner diameter; two
level sensors are mounted at the bottom of each of the lower tanks. The system is designed as
a portable unit where the surface 1 can be attached to the reservoir to form a brief case
structure. As shown in Figure 2-11, the piping of the system is such that the output of
Pump02 feeds Tank 1 and Tank 4 via Valve 1 (three-way valve). Similarly, output of Pump01
feeds Tank 2 and Tank 3 via Valve 2 (three-way valve). The leakages from Tank 4 and Tank
3 flow into Tank 2 and Tank 1 respectively. The levels of Tank 1 and tank 2 are measured by
the level sensors mounted at the bottom of each tank but the levels of Tank 4 and Tank 3 are
not measured.
1 This surface is formed by the combination of the four tanks and the frame on which they are mounted.
31

Figure 2-10: Four-tank laboratory process equipment
2.8.1 System description
The diagram depicted in Figure 2-11 shows diagrammatic representation of the four tank
process and how it is connected to a computer via a DAQ 1 device.
1 Data Acquisition
32

Tank 3 Tank 4
Three – way valve-2
Three-way valve -1
Level sensor-2
Tank 1
Tank 2
Level sensor-1
A/O
A/I
A/O
A/O
DAQ-2
Pump 02
Pump 01
A/O A/I
DAQ-1
Bottom reservoir
computer
Figure 2-11: Diagrammatic representation of the four-tank process
The components of the system are described as follows;
2.8.1.1 Water reservoir
The bottom reservoir is made out of aluminium (Al) which gives less weight to the structure
as well as resistance to corrosion.
2.8.1.2 Pumps
Two 12 Volt DC Johnson impeller pumps are used in this process. They are labelled as Pump
01 and Pump 02 as shown in Figure 2-11. They are located in a small pump room which is
adjacent to the reservoir. The pumps are designed to operate within a voltage range of 0 to
12V.
Two amplifiers are used with the two pumps in order to convert the 0 to 5V electrical signal
from the DAQ device to 0 to 12V that will be required to operate the pumps. A 15V power
supply is used to supply power to the amplifiers.
33

2.8.1.3 Valves
Two Samson brand three-way valves are used for this system. They are labelled as three-way
valve-1 and three-way valve-2 as illustrated in Figure 2-11. They are linearly operated valves
and require a 0 to 5V control signal for operation and a 24 Volt AC electrical supply is used to
power up the valves.
2.8.1.4 Level sensors
Two screw type pressure transmitters made from BD Sensors are used for this process and
they are labelled as Level sensor-1 and Level sensor-2 as shown in Figure 2-11. Both are
mounted at the bottom of the two lower tanks. The measurement range of these sensors are 0 -
40 [mbar] corresponding to 0 - 400 [mmH 2 O], this is within acceptable accuracy limits of the
process [21].
The level sensors used for this process gives out a 4-20mA current signal. The voltage across
the resistor varies from 2 – 6 [V], and so the voltage is scaled from 2 – 6 [V] to 0 – 20 [cm]
representing the height of the tank [20]. The level sensors require a 12 – 36 [V] DC supply.
The signal conditioning requirements of the sensors are;
• 2 × 0 – 40 [mbar] pressure sensors that outputs 4 – 20 [mA] current signal
• 2 × 500Ω resistor
• 24 [V] DC supply
The signal flow of the level sensors is shown in Figure 2-12
Figure 2-12: Signal flow and scaling from sensor to LabVIEW application
2.8.1.5 Data Acquisition
Two NI USB-6008 DAQ devices from National Instruments are used in this process as shown
in Figure 2-13. Each device is equipped with four differential analogue input channels and
two differential analogue output channels, it is a 12-bit device and the sampling rate is 10 k
samples/s.
34

Figure 2-13: NI USB-6008 DAQ device from National Instruments
2.8.2 Mathematical Model of the Four Tank Process
The mathematical model for the four-tank process as deduced in [21] was derived by applying
the mass balance and Bernoulli’s theorem to each tank. Then the model can be described as a
non-linear differential equations as shown in equations (2-1), (2-2), (2-3) and (2-4).
where:
2
2
( 2-1)
2
2
( 2-2)
2
( 2-3)
2
( 2-4)
• A i - cross-sectional area of Tank i
• a i - cross-sectional area of the outlet hole
• h i - the water level in Tank i
• v i - voltage applied to pump i
• k i v i - flow from pump i
• g - acceleration due to gravity
• γ i – valve parameter for the valve i
The equations (2-1), (2-2), (2-3) and (2-4) can be represented in the general form of a state
space model as,
35

( 2-5)
( 2-6)
Where x, y and u is the state vector, output vector and input vector respectively. The system
has four (4) state variables h 1 , h 2 , h 3 and h 4 in the x vector, v 1 and v 2 are the two variables in
the u vector , the y vector consists of h 1 and h 2 variables and then the A, B, C and D are
matrices and D = 0 [21].
The Taylor series is used around the four nominal values ,
, and in order to obtain
a linear model.
The system can be written as,
0
0
0
0
0 0
0
0 0 0
0
0
0
( 2-7)
0
0 0 0
0 0 0 ( 2-8)
( 2-9)
( 2-10)
According to [21], k c is taken as a calibration constant and chosen as 1 and the time constants
for the tanks T i are given as
for i = 1...4 ( 2-11)
, ∈ 0,1 is determined from the valve setting before the start-up of an experiment for
tanks 2 and 3 and corresponding tanks 1 and 4 respectively. The level sensors are calibrated
considering k c = 1 as presented in [21].
The overview of the states, parameters and nominal state values are shown in Table 2-1.
Table 2-1: Overview of states, parameters and nominal values [21]
Symbol State/ Parameter Values
, , , Nominal levels 11.8, 12.5, 5.5, 9.5
,
Nominal pump settings 3.75, 3.7
Area of the tanks 28
36

Area of the drain in tank i 0.16, 0.13, 0.16, 0.13
Ratio of the flows in the
valves
Pump proportionality
constant
0.4, 0.4
0.67, 0.74
Gravitational constant 981
Time constant in the
linearised model
27.78, 35.56, 18.54, 30.94
The overview of the controller is shown in Figure 2-14, the PID controller is used to control
the process. A mathematical equation for a PID controller is shown in equation (2-12).
( 2-12)
Where u 0 is the nominal value for control variable, K p is the proportional gain, T i [s] is the
integral time and T d [s] is the derivative time.
Figure 2-14: Overview of the control system and the process
The PID parameters for the two controllers were obtained as Kp1 = 0.9, Ti1 = 5, Kp2 = 0.8
and Ti2 = 4.1 as presented in [21].
37

2.9 Database systems
A collection of (usually) organized information in a regular structure may be defined as a
structured collection of records stored in a computer, so that an application can use it to
answer queries [1]. Records are a collection of several data types with same type of
information and an application used to manage and query database is called Database
Management System (DBMS). The schema is a term which refers to structural description of
type of data held in the database. The diagram in Figure 2-15 shows the structure of a
database (data hierarchy).
Figure 2-15: Data Hierarchy Schema, Records and data in a database [1]
The Supervisory Control and Data Acquisition (SCADA) have a feature of collecting data
amongst one of its numerous features, from RTUs, PACs, PLCs and a host of other field
devices. A typical SCADA system has hundreds or thousands of interface points to the
physical process. This makes it impossible to manage the information from each in the
software module without a database. The diagram in Figure 2-16 shows a SCADA system
with database. Time series database are used for runtime data/historical data, configuration
database may be any database model and SQL database for the management system
38

Figure 2-16: Example of SCADA system with database [1]
The software systems consist of standard software modules, configuration tools for obtaining
information for each point in the physical process and the configuration data. The
configuration data are [22]
• Parameters for all sensors and actuator (all input and output devices)
• Parameters for computation of derived variable
• Events definition and connection with control actions (if needed)
• Controller parameter
Configuration parameters are specific for each tag in the physical process and are required to
be stored outside the software modules creating independency of the software module from
the size of the physical plant. The configuration is saved in a database system so that the
configuration tool and the software modules have access to the configuration data.
The interface between the database system and the applications using the data base will
include [1];
1. Support for data input to the database system
2. Support for data output from the database system
3. Data representation
4. Support for command input to the database system
The diagram in Figure 2-17 shows a real time process database and applications for data
access, The User interface has the command inputs from the operator (control purposes) and
administrator (configuration) and the output connects to the presentation of process data in a
format a user understands like display of dynamic attribute of tags and values (process
variables). The Alarm log prints from the Alarm statistics. The application modules that
interface the database with the plants are the sensor data input and filtering responsible for
data acquisition and the actuator control interfaces the database with the output devices like
pumps, valve, and motor among others.
39

Digital regulator program contains controller algorithm for computation of control signals.
The main parameters describing a point are listed as follows [22];
• Code
• Name/Description
• Type
• Address/Physical reference
• Event class
• Alarm class
• Sampling time
• Raw value
• Converter value
• Alarm state
For analogue point these parameters are needed for conversion from raw values to
engineering units
• Scaling factor
• Measuring units
• Minimum and maximum values
40

Figure 2-17: Diagram of real time database and applications for data access [22]
41

PART II
42

3 ANALYSIS OF SOFTWARE
This section shows how the software was analysed in detail using the concepts of OOA.
Proper analysis helps in outlining the scope of the software application and according to [23]
poor scope definition is one of the main reasons why software projects fail. The overview of
the analysis phase is shown in Figure 3-1.
Figure 3-1: Analysis Phase of the SCADA software development [1]
3.1 Requirements
The requirements of the software were carried out by using FURPS+ and are outlined below;
F Functionality
1. The SCADA application should be module based and have a control (desktop)
application (system) that will be hosted on a computer in the same location as the
four-tank process, a configuration system that will be hosted on a web browser, and a
monitoring system that will also be hosted on a web browser.
2. The SCADA application should have the ability to monitor and control the four-tank
process.
• The client application should be able to read and write/save data to the
database.
• The control application should be able to read and write data to the four-tank
process and read and write/save data to the database.
3. The SCADA application should have an interactive user interface that is easy to
understand with few color combinations.
4. The control application should be developed using WPF and the client application
should be developed using Silverlight.
43

U Usability
R Reliability
• Having failover 1 capabilities.
P Performance
• Maximum of 0.2 seconds sampling time between the control application and the fourtank
process.
• Maximum of 2 seconds loop time between the control application and the database.
• 24 × 7
S Supportability
• Windows OS with Silverlight
+ Design Limitations
3.2 Use cases
The usecase defines what the system in its entirety shall do and it treats the system as a
blackbox [23]. It shows the interactions between the actors and the system in order to
accomplish a goal. The actors refer to those components that are external to the system but
have certain roles that relate to the system [24].
The usecase does not show how the system shall carry out the functions but on what the
system will accomplish. The usecase is very important in defining the scope of the software
application. The usecase diagram for the SCADA application is shown in Figure 3-2 and is
explained as follows;
SCADA server:
All associations with the Operator and Admin actors go through the WAN. The Configuration
and SQL usecases have no associations with the Operator actor. The SQL usecase have no
association with the Operator and Admin actors. The Configuration usecase only informs
(send trigger) the Control Algorithm usecase that some parameters have been changed in the
database and that those parameters have to be updated in the Control Algorithm usecase.
Control Application:
The Control Pump, Control Algorithm, and Read Sensor usecases on the Control Application
have no associations with the Operator and Admin actors as they only act as an interface to
the pumps. The Control Algorithm and Read Sensor usecases have associations with the SQL
usecase via the WAN.
1 Ability to control the process by utilizing the configuration in a configuration back-up file when the WAN
connection is broken.
44

Control Application
SCADA server
System
System
Configuration
Control Pump
Database
Admin
Pumps
Configuration file
SQL
Control Algorithm
Alarm system
Timer
Timer2
Monitoring
Read Sensor
Operator
Sensors
Reporting
Printer
Figure 3-2: Use case diagram of the SCADA system
3.3 Domain model
Based on [23], the domain model is static information of the domain entities that shows a
representation of the real situation conceptual classes.
It identifies the relationships among all the entities within the scope of the problem domain
and commonly identifies their attributes [25]. The domain model for the SCADA application
is shown in Figure 3-3.
45

SCADA System
SCADA Server
Printer
Control Application
Disk
SQL
Configuration File
WAN
Timer2
Timer
DAQ
Alarm System
Sensor
Pump
Operator
Admin
Figure 3-3: Domain Model of the SCADA system
3.4 Fully dressed use case document
The FDUCD is a text document describing each of the usecases in detail showing how the
software shall accomplish the specified functions. The FDUCD for the usecases are presented
in appendix B2.
3.5 System sequence diagram
The SSD describes the dynamic functions of the system by showing the events that takes
place from the system to the actors and vice versa as presented in [23].
According to [23], the SSD describes what the system shall do and not how to do it. A SSD is
developed for each usecase (see Figure 3-2) and it is based on the information in the FDUCD.
The SSDs for the system is shown in appendix B1.
3.6 Sequence diagram
The sequence diagram shows the sequence of the messages between the objects (classes) as
they occur with time. The sequence diagram for the system is shown in appendix B3. The
sequence diagram is developed based on the information from the SSD and the domain model
as shown in Figure 4-1.
46

4 SYSTEM DESIGN
4.1 Design of Software
The interaction between the analysis and design phases of the SCADA application
development is shown in Figure 4-1.
Figure 4-1: Analysis and Design phases of the SCADA software development [1]
4.2 Graphic Design of User Interface
This section shows the graphic design adopted for the user interface of the various pages in
the SCADA application which was developed using Microsoft Visio.
4.2.1 Navigation chart
The chart shows the sequence of the navigation from the main page to the various functional
pages and vice versa in the SCADA application as shown in Figure 4-2.
Figure 4-2: Chart showing the navigation flow
47

4.2.2 Login page
When the application is initialised, there will be a login prompt where the login details will be
entered by the user (admin or operator) before gaining access see Figure 4-3.
Figure 4-3: Design of the Login page of the SCADA application
4.2.3 Main page
After authentication from the login page, the system opens up the main page with various
navigation buttons as shown in Figure 4-4.
The admin user will have unlimited access to all parts of the application while for the
operator, the configuration button will be disabled because the operator should only be able to
adjust the setpoint reference and the valve which can be done from the monitoring page as
shown in Figure 4-11.
Figure 4-4: Design of the main page of the SCADA application
48

4.2.4 Configuration page
The configuration page is an environment where parameters related to the control application,
data logging, alarm configuration and reporting can be configured as shown in Figure 4-5.
Figure 4-5: Design of the configuration page of the SCADA application
4.2.5 Alarm page
The alarm page presents the list of all the active and acknowledged alarms as shown in Figure
4-6. The page has an ’Acknowledge’ button that the operator uses to acknowledge an alarm
by clicking it. The ’Acknowledge All’ button is used by the operator to acknowledge all the
alarms that are displayed on the page. The design of the alarm page shown in Figure 4-6 is
according to the standard presented in [1].
49

Figure 4-6: Design of the alarm page of the SCADA application [1]
4.2.6 Control application configuration page
A child window is opened when the ‘Control application’ button is clicked which has a tab
control that consists of configurable parameters related to the control application. This is the
environment where the administrator can configure these parameters.
The tab control consists of four tabs namely
• Setpoint
• Tank 1 control
• Tank 2 control and
• Timer
as shown in Figure 4-7.
50

Figure 4-7: Design of the control application configuration page of the SCADA application
51

4.2.7 Configure alarm page
A child window is opened when the ‘Configure Alarm’ button is clicked which presents an
environment for the configuration of the High-High, High, Low, and Low-Low alarm limits
as shown in Figure 4-8.
Figure 4-8: Design of the configure alarm page of the SCADA application
52

4.2.8 Configure report page
When the ’Configure Report’ button is clicked, a child window is opened that presents
options for the plant history data report and the alarm history data report. Individual tags can
be selected for each of the options for the purpose of generating a report. Also, the desired
duration of interest can also be configured (daily, weekly etc) in this page as shown in Figure
4-9.
Figure 4-9: Design of the configure report page of the SCADA system
53

4.2.9 Report page
When the ‘Report’ button is clicked on the main page a report page should be presented to the
user that looks like what is shown in Figure 4-10. The page has options for the particular day,
month, or year in which a report should be generated as well as a ‘Start’ and ‘End’ time
option.
Figure 4-10: Design of the report page of the SCADA system
4.2.10 Monitoring page
The monitoring page contains the information concerning the setpoint of tanks 1 and 2,
controller output for pumps 01 and 02, level of tanks 1 and 2 etc. It also gives a dynamic
representation of the four-tank process as shown in Figure 4-11.
The monitoring page also has a section that shows the current active alarm, an alarm indicator
and an ’Acknowledge Alarm’ button.
The child window for the setpoint configuration pops up when the ‘Change setpoints’ button
is clicked in order to change the setpoint for tanks 1 and 2. This is due to the fact that the
54

access level only permits the operator to change the setpoint of the tank levels and valves,
which was the motivation for the design of this option.
Monitoring
Alarm Status:
No Alarm
Acknowledge Alarm
Main menu
Tank 1
Tank 2
Configuration
Valve 1 setpoint:
Valve 2 setpoint:
Alarm
Tank 1 setpoint
Tank 2 setpoint
Report
Controller output 1:
Tank 3 Tank 4
valve 1 Valve 2
Controller output 2:
Tank 1 level:
Tank 2 level:
Tank 1 Tank 2
Setpoint Configuration
X
Pump 01 Pump 02
Tank 1 set point:
Tank 2 set point:
Change setpoints
Valve 1 set point
Valve 2 set point
Save
Close
Figure 4-11: Design of the monitoring page of the SCADA system
4.2.11 Control application
The control application has an indicator named ‘Configuration data’ that shows where the
configuration data was loaded (database or backup file) from. A child window is opened
when the ‘Configuration’ button is clicked, this window will have the same design and
functions as the child window in Figure 4-7. The application has one button for starting the
control application, and one for stopping the control application. A status window named
‘Control application status’ will show the current state and errors. The monitoring part will be
55

of the same design as the monitoring page. The design of the control application is shown in
Figure 4-12.
Configuration data:
Configuration
Tank 1
Valve 1 setpoint:
Tank 1 setpoint
Tank 2
Valve 2 setpoint:
Tank 2 setpoint
Start
Stop
Controller output 1:
Tank 3 Tank 4
valve 1 Valve 2
Controller output 2:
Control application status:
Tank 1 level:
Tank 2 level:
Tank 1 Tank 2
Pump 01 Pump 02
Figure 4-12 Design of the control application
4.3 Design of database model
A relational database model was adopted and was designed using Microsoft Visio as shown in
Figure 4-13. It can be seen that the TagId and TaskId are foreign keys in the TagTask table
since the TagTask table links the Tag and Task tables. Also, the ControllerId and TagId are
foreign keys in the TagController table since the TagController table links the Tag and
Controller tables.
According to [26] and [27], the primary key uniquely identifies each record in the table while
the foreign key is a field in a relational table that matches the primary key column of another
table and is used to cross-reference tables.
56

Figure 4-13: Database model adopted for the SCADA system
57

5 IMPLEMENTATION OF SOFTWARE
This section shows the parts of the design that were implemented in the prototype along with
the assumptions. The alarm, report and data logging parts of the SCADA application were not
implemented in the prototype.
5.1 Control application
In this section, the implementation of the control application will be explained. There is some
simplified code examples through this section that will help the reader understand the
methods that were used while coding the application. For the full code solution, please see the
Microsoft Visual Studio project file for the control application located on the CD in Appendix
D (the project name is DAQcontrolApp).
5.1.1 Configuration files
The control application uses two external files called DAQcontrolApp.exe.config and
ConfigBackup.txt. The DAQcontrolApp.exe.config file contains the database connection
string, views and stored procedures used in the SCADA system. The reason why this was
done is to allow the SQL configuration to be changed without recompiling the application
project. The content of this file is shown in Figure 5-1.
Figure 5-1: The SQL configuration file DAQcontrolApp.exe.config content.
The ConfigBackup.txt file contains the latest configuration data that was received by the
control application. The idea behind this backup file is that if the database is unavailable, the
control application can still be started and run. The content of this file is shown in Figure 5-2.
58

Figure 5-2: The configuration backup file ConfigBackup.txt content.
The following C# code example shows how the database connection string is read from the
DAQcontrolApp.exe.config file that is placed in the same folder as the application:
SQLconfig[0] = ConfigurationManager.AppSettings["DBconnStr"];
The following C# code example shows how to read and write to the ConfigBackup.txt file
that is placed in the same folder as the application:
First we get the application location:
string AppLocation =
System.IO.Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
To ‘read’, the following code was used :
config = System.IO.File.ReadAllLines(AppLocation + @"\ConfigBackup.txt");
To ‘write’, the following code was used:
System.IO.File.WriteAllLines((AppLocation + @"\ConfigBackup.txt"), *input array*);
where the *input array* is an array containing all the different values that will be written to
the file.
5.1.2 Initialization
When the control application is opened an initialization will start, first the database
connection information is loaded from the .config file (DAQcontrolApp.exe.config) into the
application. Then the application will try to connect to the database and retrieve the
configuration values, if connection attempt fails the application will load the configuration
from a backup file (ConfigBackup.txt). This operation is done by using a try-catch statement;
if the try block creates an exception (connection to database fails) the code in the catch block
will be executed. An example of a try-catch statement in C# is shown below:
59

try
{
}
catch
{
}
//Try connecting to the database and load configuration.
//Try block creates an exception during execution (database connection
fails), load configuration from backup file.
The control application configuration and backup file will automatically be updated when the
configuration values are changed in the database. A trigger (appendix C) in the database will
detect an update change in one of the configuration tables, this trigger will then set a related
flag value (in database flag table) to 1. This flag is sent to the application each time the
application updates the tag values in the database, if the flag is equal to 1 the control
application will retrieve the new configuration and update the backup file. The control
application will show where the configuration data was loaded from (database or backup file).
When the configuration is loaded, the DAQ outputs will be initialized such that valves go to
the positions defined in the configuration, and the pump outputs are set to 0V. Now if the
configuration is successfully loaded and both DAQ’s are connected the start button will be
enabled so the control application can be started, this is shown in Figure 5-3.
Figure 5-3: The control application UI when initialized and ready to run.
If the control application fails to load the configuration or the DAQ’s are not connected to the
computer, the start button will not be enabled and an error message will appear in the status
field (lower-left corner), this is shown in Figure 5-4.
60

Figure 5-4: The control application UI if the DAQ connection fails.
5.1.3 Database communication
An own class (DBconnection) in control application has been created to handle the database
communication (both read and write). In order to communicate with the database, a
connection is opened with a connection string:
Server=tcp:JINX\SQLEXPRESS,1433;Database=SCADA;User Id=sa;Password=Neverhood
In this string, a connection to a database called SCADA is established on a computer named
JINX through TCP port 1433 (instance name is SQLEXPRESS). The database user id is sa and
the password is Neverhood. When the connection is established the query command can be
executed, after the database response is saved to a data set the database connection should be
closed (asynchronous query). A C# code example on how this works is shown below:
conn = new SqlConnection(*Connection string*);
conn.Open();
SqlCommand command = new SqlCommand(*query command*, conn);
SqlDataAdapter adapter = new SqlDataAdapter(command);
DataSet DatabaseResponse = new DataSet();
adapter.Fill(DatabaseResponse);
conn.Close();
5.1.4 DAQ communication
In order to communicate with a DAQ (Data Acquisition) from NI (National Instruments), four
assembly files needs to be added to the control application (we only need to add two
references, the dll files are automatically added to the compiled solution), all of these files are
provided by NI and are called:
• NationalInstruments.Common
• NationalInstruments.Common.dll
61

• NationalInstruments.DAQmx
• NationalInstruments.DAQmx.dll
These assembly files did not have support for Silverlight 4 during the project, so a WPF
(Windows Presentation Foundation) application was created instead. WPF applications are
similar to Silverlight applications as both uses XAML and .NET programming languages (C#,
VB etc.).
The DAQ tasks that are used must also be present at the computer that runs the control
application. These tasks can either be imported to a computer with MAX (Measurement &
Automation Explorer) from NI through a task configuration file (.nce), or created with MAX.
The task configuration file for this project is included for easy deployment (for more
information, please see section 6.2).
In the control application, there are four tasks that must be present see Table 5-1:
Table 5-1: DAQ task descriptions
Task name:
SCADAinput1
SCADAinput2
SCADAoutput1
SCADAoutput2
Description:
Read data from DAQ 1 input, this is the
sensor data for tank 1. The input range is
from 2V to 6V.
Read data from DAQ 2 input, this is the
sensor data for tank 2. The input range is
from 2V to 6V.
Write data to DAQ 1 outputs, these are the
pump 1 and valve 1 control signals. The
output range is from 0V to 5V.
Write data to DAQ 2 outputs, these are the
pump 2 and valve 2 control signals. The
output range is from 0V to 5V.
All of the tasks have Sample on demand as acquisition method. In the control application, two
classes have been created to handle the DAQ communication for reading (DAQReadSensor)
and writing (DAQWriteOutput) to the two DAQs used in the four tank process.
To read a single channel, the C# code (s_value is the sensor value) example below can be
used:
using (Task AnalogRead = DaqSystem.Local.LoadTask(*task name*))
{
AnalogSingleChannelReader reader = new AnalogSingleChannelReader(AnalogRead.Stream);
s_value = reader.ReadSingleSample();
62

}
To write to multiple channels, the C# code example below can be used:
using (Task AnalogWrite = DaqSystem.Local.LoadTask(*task name*))
{
AnalogMultiChannelWriter writer = new AnalogMultiChannelWriter(AnalogWrite.Stream);
writer.WriteSingleSample(true, *output array*);
}
When reading the sensors, the DAQ input needs to be converted before the values can be
used. The 2 - 6 [V] input must be converted into 0 - 20 [cm] (tank height). This is done by the
simple calculation below:
Converted sensor value = (5 * sensor value) – 10
When converting from 0 - 20 [cm] to 0 – 5 [V], only dividing by 4 is required (multiply by 4
when going from volt to cm).
5.1.5 Starting the control application
When the control application is initialized (without errors), the application can be started by
clicking the enabled ‘start’ button on the left side of the UI (User Interface), shown in Figure
5-3.
When the start button is clicked the control application will initialize the control algorithm
class (ControlAlgorithm) with the configuration values needed and start two timers named t1
(ControlTimer1) and t2 (ControlTimer2). A message confirming that the application is
running will be shown in the status field, the stop button will be enabled and the start button
will be disabled, this is shown in Figure 5-5.
63

Figure 5-5: Running control application.
With timers, events (containing a piece of code) are triggered that are repeated after a given
time. In the control application t1 triggers (Tick) each 100 ms and t2 triggers (Tick2) each
second (1000ms).
C# code example on how to create and start a timer:
DispatcherTimer t1 = new System.Windows.Threading.DispatcherTimer();
t1.Tick += new EventHandler(Tick);
T1.Interval = new TimeSpan(*days*, *h*, *min*, *s*,*ms*));
T1.Start();
In timer t1 the control application reads the DAQ input (sensor values), calculate the new
controller output, write to the DAQ outputs (pumps and valves) and update the UI. In timer t2
the control application will update the database with new tag values.
The code that t1 triggers (Tick1) can be seen below:
private void Tick(object sender, EventArgs e)
{
//Read sensor values
SensorValues = Read.ReadSensor();
//Calculate PI-controller output.
ControlOutput = CA.CalculateOutput(Configuration[10], Configuration[11],
SensorValues);
//Write values to DAQ outputs.
Write.WriteOutput(ControlOutput, Configuration[12], Configuration[13]);
}
//Update UI with new sensor values
CAout1.Text = Convert.ToString(ControlOutput[0]);
CAout2.Text = Convert.ToString(ControlOutput[1]);
SensorValue1.Text = SensorValues[0];
SensorValue2.Text = SensorValues[1];
Tank1.Value = 5 * Convert.ToDouble(SensorValues[0]);
Tank2.Value = 5 * Convert.ToDouble(SensorValues[1]);
64

The code that t2 triggers (Tick2) can be seen below:
private void Tick2(object sender, EventArgs e)
{
string[] TagValues = new string[6];
//Update the array that containing the newest tag values.
TagValues[0] = Configuration[12];
TagValues[1] = Configuration[13];
TagValues[2] = Convert.ToString(ControlOutput[0]);
TagValues[3] = Convert.ToString(ControlOutput[1]);
TagValues[4] = SensorValues[0];
TagValues[5] = SensorValues[1];
//Update database with the newest tag values and get UpdateFlag value.
try
{
UpdateFlag = DB.DBwrite(TagValues);
}
catch
{
}
ControlAppStatus.Text = "ERROR: Cant write to the database.";
}
//Update configuration if UpdateFlag is true.
if (UpdateFlag == true)
{
Configuration = InitializeConfig();
UpdateFlag = false;
}
5.1.6 Control algorithm
In the control application, a class (ControlAlgorithm) have been created to calculate the DAQ
outputs that controls pumps 1 and 2. This class contains a control algorithm used to control
the water level in tanks 1 and 2 (the algorithm is a PI-controller). The controller setpoints are
given from 0 to 20 cm (height of tanks 1 and 2).
The control algorithm that was used can be seen in equations (5-1), (5-2) and (5-3):
( 5-1)
∗ ( 5-2)
∗ / ∗ ( 5-3)
where
e - is the difference (error) between the setpoint reference and process measurement
(controller input).
r - is the setpoint reference.
y - is the process measurement (sensor values).
u - is the controller output (pump outputs).
Kp - is the proportional gain for the PI-controller.
65

Ti - is the integral time for the PI-controller.
dt - is the sampling time of the application in seconds (default 0.1 [s])
A fail-safe has been implemented to prevent the controller output from exceeding the DAQ
output range. This is done after the controller output has been converted from cm to V.
5.1.7 Control configuration
The controller configuration can be changed inside the control application; this is done by
clicking on the configuration button found on the left side in the UI see Figure 5-3. When this
is done a child window appears, in this window the user can see the current controller
configuration and will be able to make changes to it. When the changes are finished, click the
‘Save’ button in order to store the new configuration in the database (and backup file), if the
‘Close’ button is clicked, the changes will not be saved and will be discarded and the window
will be closed. The Child window with the different tabs is shown in Figure 5-6.
66

Figure 5-6: Controller configuration child window with the different tabs.
5.1.8 Stopping the control application
In order to stop the control application properly, a shutdown procedure have been created.
When the stop button is clicked:
• Both timer t1 and t2 will stop.
• The DAQ pump outputs will be set to 0.
• Status field is updated confirming that the control application is stopped.
• UpdateFlag is set to false.
• Water level in tank 1 and 2 in the UI will be set to zero.
• Start button enabled and Stop button disabled.
67

5.2 Silverlight application
In this chapter the implementation of the Silverlight application will be explained. There is
some simplified code examples through this section that will help the reader understand the
methods that were used while coding the application. For the full code solution, please see the
Microsoft Visual Studio project file for the Silverlight application located on the CD in
Appendix D (the project name is SCADAapp).
5.2.1 WCF service
Windows Communication Foundation (WCF) is a framework for building service-oriented
applications as presented in [17]. If a database is to be accessed with the Silverlight
application, a WCF service that handles the communication needs to be created (the WCF
service will be placed on the .Web part of the Silverlight project).
The Silverlight application that is created have three WCF services, one for reading from the
database, one for writing to the database and one for checking the username and password
when a user logs in. The C# code behind the database communication is of the same method
as the one used in the control application (see section 5.1.3 for more details).
The read service can return 2 different arrays depending on what read option that was chosen,
the options are shown in Table 5-2. The write service only contains one option (write option
0), and this option will write the given configuration (array) to the database.
Table 5-2: WCF read service options
Read option:
Description:
0 Returns the controller configuration.
1 Returns the values used in the monitoring
page (valves, pumps, sensors and setpoints).
When the service references (read and write) are added to the project part of the Silverlight
application, the WCF services can then be called. The C# code below shows how the
Silverlight application calls the read WCF service to get the configuration (read option 0):
int ReadOption = 0;
ReadServiceClient rclient = new ReadServiceClient();
rclient.ReadDatabaseCompleted += new
EventHandler(client_ReadDatabaseCompleted);
rclient.ReadDatabaseAsync(ReadOption);
void client_ReadDatabaseCompleted(object sender, ReadDatabaseCompletedEventArgs e)
{
68

}
Configuration = e.Result.ToArray();
The SQL configuration required for database communication (same as in the control
application) is located in the Web.config file (this file already existed in the .Web part of the
Silverlight application; see section 6.3 for more information).
5.2.2 Login Page
In the login page the user will be able to log into a personal account (own username and
password), the two different types of accounts are Administrator and Operator. The
Administrator account type has access to everything (Figure 5-9), while the Operator account
type does not have access to the configuration page (Figure 5-10). To proceed to the main
page of the SCADA system, a valid username and password must be entered before clicking
the login button, the UI is shown in Figure 5-7. The default usernames and passwords have
been set to be the same as the user account type (User: Administrator, Password:
Administrator).
Figure 5-7: Login page for the Silverlight application.
The Silverlight application will use the WCF login service to check the entered username and
password against the username and password list in the database. If the wrong username or
password is entered a message will appear stating that the username or password is wrong,
shown in Figure 5-8. If the right password is entered the user will be navigated to the main
page and the navigation buttons will be enabled depending on the account type.
69

Figure 5-8: Login page if login fails (wrong username or password).
Figure 5-9: Main SCADA page when login is successful as Administrator.
5.2.3 Main Page
After the login, the user will be navigated to the SCADA main page. Depending on the
account type, different buttons will be unlocked. The C# code below shows how the buttons
are unlocked:
private void LoginLevel()
{
if (UserLevel == "Administrator")
{
monitoringButton.IsEnabled = true;
ConfigButton.IsEnabled = true;
ReportingButton.IsEnabled = true;
AlarmButton.IsEnabled = true;
}
}
if (UserLevel == "Operator")
{
monitoringButton.IsEnabled = true;
ReportingButton.IsEnabled = true;
AlarmButton.IsEnabled = true;
}
70

The UserLevel variable is provided from the login page. If the Administrator account is used,
the main page will be as shown in Figure 5-9, if the Operator account is used, the main page
will be as shown in Figure 5-10.
Figure 5-10: Main SCADA page when login is successful as Operator.
The C# code below shows how the application navigates to the monitoring page when the
‘Monitoring’ button is clicked, the user level is provided to unlock the configuration button (if
administrator) on the quick navigation menu.
private void monitoringButton_Click(object sender, RoutedEventArgs e)
{
this.Content = new Monitoring(UserLevel);
}
5.2.4 Monitoring page
When the Monitoring page is opened (see Figure 5-11), it will initialize and start timer t
(triggers every 2 seconds). Timer t (Tick) is of the same type as the one used in the control
application (see section 5.1.5 for details). This timer will use the WCF read service (with read
option 1) to get the newest tag and setpoint values from the database, when the values are
received the UI is updated, the code is shown below:
private void Tick(object sender, EventArgs e)
{
ReadServiceClient client = new ReadServiceClient();
client.ReadDatabaseCompleted += new
EventHandler(client_GetTagsCompleted);
int ReadOption = 1; //To read the monitoring values: ReadOption = 1
client.ReadDatabaseAsync(ReadOption);
}
void client_GetTagsCompleted(object sender, ReadDatabaseCompletedEventArgs e)
{
TagValues = e.Result.ToArray();
//Update Monitoring display.
Valve1.Text = TagValues[0];
Valve2.Text = TagValues[1];
71

Pump1.Text = TagValues[2];
Pump2.Text = TagValues[3];
Sensor1.Text = TagValues[4];
Sensor2.Text = TagValues[5];
Setpoint1.Text = TagValues[6];
Setpoint2.Text = TagValues[7];
}
progressBar1.Value = 5 * Convert.ToDouble(TagValues[4]);
progressBar2.Value = 5 * Convert.ToDouble(TagValues[5]);
Figure 5-11: Monitoring page for the SCADA system.
The tank and valve setpoints can be changed from the monitoring page, to do this click the
‘Change setpoints’ button at the bottom of the monitoring page (see Figure 5-11). This will
bring up a child window (see Figure 5-12) that allows the user to change the setpoints, C#
code shown below:
private void SetpointConfig_Click(object sender, RoutedEventArgs e)
{
SetpointConfig SetpointConfiguration = new SetpointConfig();
SetpointConfiguration.Show();
}
72

Figure 5-12: Setpoint configuration child window.
In the child window the user can see the current setpoint values and change it. When the
changes are finished click the ‘Save’ button in order to store the new setpoints to the database,
if the ‘Close’ button is clicked, the changes are not saved and will be discarded and the
window will be closed.
5.2.5 Configuration page
From the configuration page (see Figure 5-13), all of the configuration values for the SCADA
system can be changed. For the implemented prototype, only the ‘Control application’
configuration page can be opened.
Figure 5-13: Configuration page of the SCADA system.
When the ‘Control application’ button is clicked a child window appears (see Figure 5-14), in
this window the user can see the current controller configuration and change it. When the
changes are finished click the ‘Save’ button in order to store the new configuration in the
73

database, if the ‘Close’ button is clicked, the changes are not saved and will be discarded and
the window will be closed. The Child window has the same UI as in the configuration page in
the control application; therefore see Figure 5-6 for all the different tabs.
Figure 5-14 : Control configuration child window in the Silverlight application.
5.3 Database implementation using MS SQL server
2008
The database model was implemented in MS SQL. A holistic approach was adopted in the
database implementation by creating the SCADA database, creating the tables, inserting
default values into the tables, creating stored procedures, creating views and creating triggers
all in one SQL script. The complete SQL script can be found in appendix C of this report.
5.4 Testing
The test procedure presented in [1] was adopted for the system and is as follows
• Unit test
• Integration test
• System test
From the design of the system, it had been subdivided into three modules namely; the
• Control application (WPF)
• Database
• Client application (Silverlight)
74

5.4.1 Unit Test
The unit tests were carried out on each of the modules and the procedure used for carrying out
the tests is represented in the flowchart shown in Figure 5-15.
Implementation
Test for
functionality
Test OK
No
Yes
5.4.1.1 Control application test
Ready for
Integration
Figure 5-15: Unit test procedure for SCADA system
For the control application, three usecases were present (see Figure 3-2) and the tests were
carried out based on the functionality of the application like reading values from the process,
regulating the pumps, computation of control output based on the programmed algorithm etc.
5.4.1.2 Database test
The database script had the ability of creating the database, creating the tables, inserting
default values into the tables, creating stored procedures, creating views and creating triggers
in one execution and each of these functions were tested.
5.4.1.3 Client application test
The GUI of the client application was tested based on the design that was adopted such as the
colours, the type of tank, the dynamic properties etc.
Also, since one of the main advantages of Silverlight applications is their dynamic resizing
property, hence the client application was tested to see if the dynamic resizing was achieved.
75

5.4.2 Integration test
The integration test was carried out on each of the subsystems i.e.
• Interaction between the control application and the database
• Interaction between the client application and the database
The procedure used for the test is represented in the flowchart shown in Figure 5-16.
Implementation
Test for
functionality/
interaction between
applications
Test OK
No
Yes
Ready for
Integration
Figure 5-16: Integration test procedure for SCADA system
5.4.2.1 Control application and database
Tests were carried out to see if data was being ‘read from’ and ‘written to’ the database from
the control application. Also, the tests were carried out to see if the data were being written to
the correct tables in the database.
5.4.2.2 Client application and database
Tests were carried to see if data was being ‘read from’ and ‘written to’ the database from the
client application. Also, the tests were carried out to see if the data were being written to the
76

correct tables in the database. Tests were carried out to see if the setpoint values 1 were
updated after they were changed 2 .
5.4.3 System test
The entire system was now tested from the client application to the four-tank process to see if
the requirements were fulfilled. The setpoints of the two tanks were changed from the client
application and the changes were effected in the four-tank process. The levels of the two tanks
could be monitored from the client application dynamically.
Implementation
System Test
Test OK
No
Yes
Ready for
Deployment
Figure 5-17: System test procedure for SCADA system
1 The display of the setpoint values for the two tanks on the monitoring page were programmed to be read-only.
In order to change the setpoint the ‘Change setpoints’ button has to be clicked to open a child window where the
setpoints can then be changed.
2 The changes were effected in the database and the monitoring page was checked to see if the setpoint values
were updated and vice versa.
77

PART III
78

6 DEPLOYMENT
This section gives an overview of the SCADA application interaction with the four-tank
process, how the SCADA application and the database were hosted on the server. The
overview of the entire system is shown in Figure 6-1.
Figure 6-1: Overview of SCADA system
6.1 Database deployment
For easy deployment, an SQL script has been created for MS SQL, this script will:
• Create a database named SCADA.
• Create all database tables.
• Initialize the tables with default values.
• Create the database procedures used.
• Create database views.
79

• Create database trigger.
Just run the “SCADA database.sql” file (located in the Deployment folder on the CD in
Appendix D) and execute the query inside MS SQL, note: If a database called SCADA
already exist, the user need to change the database name at the top of the script. The complete
database script is shown in appendix C. Comments have been used in the script to explain the
code so the user can understand the structure of the code.
The TCP port 1433 (database) and UDP port 1434 (SQLServerBrowser) should be opened in
the firewall on the computer hosting the database (to allow communication). The TCP port
used must also be defined in the SQL server Configuration Manager.
6.2 Control application deployment (WPF)
The control application can be executed from any location on the computer, the seven files
that are needed, must to be in the same folder. The Control Application subfolder is located in
the Deployment folder on the CD in Appendix D.
To change the database connection string, simply open the DAQcontrolApp.exe.config file
and change the line marked as connection string (this is important to change, the default
computer is JINX).
The DAQ tasks that are needed can be imported into MAX through an NI Configuration
Export file that was created for the deployment, this file is named SCADA_Task_Data.nce,
and is located in the Deployment folder on the CD in Appendix D. When importing the tasks
in MAX, you must select which DAQ devices to use (marked on the four tank process). DAQ
number 1 on the process should be selected as SCADA1 and DAQ number 2 as SCADA2.
6.3 Client application deployment (Silverlight)
The hosting of the Silverlight application was done with IIS (Internet Information Service)
7.5. For easy deployment the folder to be published in IIS is provided (located in the
Deployment folder on CD in Appendix D), but in order to get it to work two things must be
done:
1. The SQL database string must be updated for the correct database used.
2. The WCF service references must be updated in the Silverlight application so they
have the right URL address.
To update the SQL connection string, open the Web.config file located in the
*SCADA site root*\SCADAapp\ and change the line marked as connection string.
80

There are two different ways of updating the WCF service references, either by updating the
URL for the service references in MS Visual Studio (right click and select update service
reference in the solution explorer), or by opening the ServiceReferences.ClientConfig file
inside the SCADAapp.xap file and making changes to the URL manually.
If MS Visual Studio is used, open the project file and re-compile the entire application to
update the references, it’s the easiest way if the user don’t know much about how the
ServiceReferences.ClientConfig file works.
If the SCADAapp.xap (works like a .zip file) file is opened and the URL references in
ServiceReferences.ClientConfig are edited, the entire project file is not needed neither is recompilation
necessary. Just add the folder into IIS after the modifications and the SCADA
application should be hosted.
81

7 CONCLUSION AND RECOMMENDATIONS
The development of a prototype of the SCADA system for the four-tank laboratory process
was carried out successfully. WPF, SQL and Silverlight 4 together with C# programming
language were used in the implementation of the prototype. A relational database (SQL
server) was used instead of a real-time database due to the limited resources available.
Learning Silverlight 4 was a challenge considering the time constraint (about 3 months) and
implementing it in a real process within the allotted time frame. However, the comprehensive
effort of the team comprising six group members along with the wonderful supervision by the
supervisor made this a reality.
At the initial phase of the project the literature study, analysis and design of the software and
learning of Silverlight 4 were carried out. The examples provided by the Microsoft’s MSDN
web site were very helpful in learning Silverlight 4. Then at the concluding phase of the
project the following were accomplished
• Control application implementation
• Client (web) application implementation
• Database communication with the control application
• Communication between the client and database
• Deployment of the application
The alarm monitoring page in client application was designed using current standards being
used in the industry [1]. The monitoring page for the process was designed to be as simple as
possible since it is for a laboratory process. The client application was hosted using IIS and a
user guide was added to complete the deployment process.
However, it is important to note that the valve must be fully opened (considering the fact that
it is a three-way valve) for stable operation of the system due to the fact only the two lower
tanks were considered for the control strategy implemented.
Therefore, it can be inferred that the work done on the project is a good gateway towards
implementing a complete SCADA solution using one of the latest software (Silverlight 4)
available.
Some of the recommendations that are being proposed for future work in this area are as
follows
• The use of a real-time database for the SCADA system.
• Scalability by adding tags, controllers, DAQs, valves, sensors, pumps without
modifying the program.
• Implementation of advanced estimation and control algorithms for better control of the
levels of all four tanks considering the fact that it is a MIMO system.
• Improvements to the data entry operations.
• Implementing the OPC protocol and integrating it to this system.
82

• Introducing students to the proposed program to be used for developing an application
early enough.
83

REFERENCES
[1] N.-O. Skeie. (2010). Industrial Information Technology, Lecture notes for Computer
Devices, Data Communication, Field Bus, OPC, Process Database, Embedded
systems, Mechatronics, Real-time systems, Alarm System, EEx, Testing and Data
Recovery (0.6 ed.).
[2] H.-P. Halvorsen. (2010). OPC and Real-Time Systems in LabVIEW.
[3] A. Daneels and W. Salter, "WHAT IS SCADA," presented at the International
Conference on Accelerator and Large Experimental Physics Control Systems, Trieste,
Italy, 1999.
[4] http://en.wikipedia.org/wiki/Scalability. (2010, 25th November). Scalability.
[5] http://en.wikipedia.org/wiki/Redundancy_(engineering). (2010, 25th November).
Redundancy (engineering).
[6] www.ehow.com. (2010, 11th October). Types of Scada Systems.
[7] www.wonderware.com. (2010, 18th October). SCADA systems.
[8] YA711, "Principles for alarm system design (ya-711), Technical report, Norwegian
Petroleum Directorate," ed, 2001.
[9] R. Lair, Beginning Silverlight 4 in C#: Robert Lair, 2010.
[10] A. Ghoda. (2010). Introducing Silverlight 4
[11] http://en.wikipedia.org/wiki/Silverlight. (2010, 25th November). Microsoft Silverlight.
[12] http://en.wikipedia.org/wiki/Windows_Presentation_Foundation. (2010, 24th
November). Windows Presentation Foundation.
[13] B. Sempf, et al., C# 2010 All-in-One for Dummies Wiley Publishing, Inc., 2010.
[14] http://archive.devx.com/dotnet/articles/cp0901/cp0901-1/waws.asp. (2010, 24th
November). What Are Web Services .
[15] http://en.wikipedia.org/wiki/Web_Services. (2010, 24th November). Web service.
[16] http://no.wikipedia.org/wiki/ASP.NET. (2010, 24th November). ASP.NET.
[17] http://msdn.microsoft.com/en-us/library/ms731082.aspx. (2010, 24th November).
What Is Windows Communication Foundation.
[18] http://en.wikipedia.org/wiki/Windows_Communication_Foundation. (2010, 24th
November). Windows Communication Foundation.
[19] P. Brown, Silverlight 4 in Action Manning Publications Co., 2010.
[20] http://www.opcfoundation.org/. (2010, 25th Nov.). What is OPC
[21] V. O. Ademu, "Developing Advanced Control strategies for a 4-Tank Laboratory
process," Masters, Electrical Engineering, Information Technology and Cybernetics,
Telemark University College, Porsgrunn, 2010.
[22] G. Olsson and G. Piani, Computer Systems for Automation and Control, 2nd ed.
London, UK: Prentice Hall International (UK) Ltd., 1998.
[23] N.-O. Skeie. (2010). Object-Oriented Analysis, Design and Programming using UML
and C#, Lecture Notes.
[24] http://en.wikipedia.org/wiki/Usecase#Actors. (2010, 25th November). Use case.
[25] http://en.wikipedia.org/wiki/Domain_model. (2010, 25th November). Domain model.
[26] http://databases.about.com/cs/administration/g/primarykey.htm. (2010, 25th
November). Primary Key Definition.
84

[27] http://databases.about.com/cs/specificproducts/g/foreignkey.htm. (2010, 25th
November). Foreign Key.
85

PART IV
86

APPENDICES
Appendix A: Task Description
87

Appendix B: UML diagrams and FDUCD
B1: System Sequence Diagrams (SSD)
System
: Sensors : Timer
sd Measurement loop
1 : Readsensors()
2 : Convertsensorvalues()
3 : UpdateSQLdatabase()
4 : wait()
Figure B. 1: SSD of the Read sensors usecase
System
: Pumps
1 : GetControllerOutput()
2 : ConvertControllerOutputToPumpValue()
3 : UpdatePumpValue()
Figure B. 2: SSD of the Control pumps usecase
90

System
: Timer
: Sensors
1 : CheckWAN()
: Configuration file
2 *[WAN:OK] : getControllerParametersandSetpointFromSQL
3 : Update()
4 [WAN:Fail] : getControllerParametersandSetpoint()
5 : ControllerParametersandSetpoint
sensor Loop
6 : GetSensorValues()
7 : SensorValues
8 : ComputeControllerOutput()
9 : UpdateSQL()
10 : CheckConfigTrigger()
11 *[ConfigTrigger:True] : getnewConfigurationandSetpointfromSQL()
12 *[ConfigTrigger:True] : Update()
13 : wait()
Figure B. 3: SSD of the Control Algorithm usecase
91

System
: Timer2
: Operator
: Admin
1 : Get High/Low limits
sd Alarm loop
2 : Get sensor values
3 : Check sensor values against limits()
4 : Update()
5 : Update()
6 : Check for alarm trigger()
7 : If alarm trigger True: get new High/Low Limits()
8 : Wait()
Figure B. 4: SSD of the Alarm system usecase
92

System
: Admin
1 : Login()
2 : Confirm access rights
3 : Change parameters()
4 : Acknowledge change of parameters()
5 : OK
6 : Update SQL()
7 : Send Trigger to Control Algorithm()
Figure B. 5: SSD of the Configuration usecase
System
1 : If Read Queries()
: Disk
2 : get data()
3 : data
4 : If write queries()
5 : write data()
Figure B. 6: SSD of the SQL usecase
93

System
: Printer
1 : get duration
2 : get process and configuration data
3 : create report()
4 : print report()
Figure B. 7: SSD of the Reporting system usecase
Monitor system
: Timer2 : Operator
: Admin
sd Monitoring loop
1 : get sensor values
2 : update display() 3 : update display()
4 : wait()
Figure B. 8: SSD of the Monitor system usecase
94

B2: Fully Dressed Use Case Document
Table B. 1: FDUCD of Control Algorithm use case
Use case Section Comment Meaning
1 Use case name Control Algorithm
2 Scope SCADA system System
3 Level User goal
4 Primary Actor Timer
5 Stakeholders and Interests
6 Preconditions 1. Set point
2. Controller parameters
7 Success Guarantee 1. Update SQL database (for monitoring
the control signal)
2. Update configuration backup file.
3. Update control pumps
8 Main success scenario 1. Check WAN connection
2. Get controller parameters from SQL
3. Get set point from SQL
4. Update configuration backup file
5. Get sensor values
6. Compute controller output
7. Update control pumps
Basic flow
8. Update SQL database (for
monitoring the control signal)
9. Wait
10. Check update trigger from
configuration usecase
9 Extensions 1a. If WAN is broken then load controller
parameters and set point from configuration
backup file, then jump to step 5.
9a. If trigger is false, jump to 5
9b. If trigger is true, jump to 2
10 Special Requirements
11 Technology List
12 Frequency of occurrence 0.1 second
13 Miscellaneous
Conditional
/ branch
95

Table B. 2: FDUCD of Configuration Use case
Use case Section Comment Meaning
1 Use case name Configuration
2 Scope SCADA system System
3 Level User goal
4 Primary Actor Administrator
5 Stakeholders and Interests
6 Preconditions User must have access rights
7 Success Guarantee Update database
8 Main success scenario 1. Confirm access rights
2. Confirm change of parameters
3. Update database
4. Send trigger to the Control Algorithm
Basic flow
usecase.
9 Extensions 1a. If access rights is false, deny access
2a. If parameters are not confirmed, do
nothing
10 Special Requirements
11 Technology List
12 Frequency of occurrence Every time the parameters are changed
13 Miscellaneous
Conditional
/ branch
Table B. 3: FDUCD of Alarm System
Use case Section Comment Meaning
1 Use case name Alarm system
2 Scope SCADA system System
3 Level User goal
4 Primary Actor Operator
5 Stakeholders and Interests
6 Preconditions 1. Defined Alarm limits
2. Sensor values
7 Success Guarantee Display is updated
8 Main success scenario 1. Get high/low limits from SQL
server
2. Get sensor values from SQL server
Basic flow
3. Check sensor values against
high/low limits
4. Update display
5. Check for alarm trigger from
configuration usecase
6. Wait
9 Extensions 5a. If alarm trigger is true: update high/low
limits.
10 Special Requirements
11 Technology List
12 Frequency of occurrence 0.1 seconds
13 Miscellaneous
Conditional /
branch
96

Table B. 4: FDUCD of SQL
Use case Section Comment Meaning
1 Use case name SQL
2 Scope SCADA system System
3 Level User goal
4 Primary Actor Operator
5 Stakeholders and Interests
6 Preconditions 1. Active connection between SQL
and database
2. Access rights
7 Success Guarantee Request executed
8 Main success scenario 1. Handle queries/requests Basic flow
9 Extensions 1a. Incoming writing requests, write to
Database
1b. Incoming reading requests, read from
Database
10 Special Requirements
11 Technology List
12 Frequency of occurrence Each time a request is received
13 Miscellaneous
Conditional /
branch
Table B. 5: FDUCD of the Report system
Use case Section Comment Meaning
1 Use case name Report system
2 Scope SCADA system System
3 Level User goal
4 Primary Actor Printer
5 Stakeholders and Interests
6 Preconditions SQL must be queried
7 Success Guarantee Printed report
8 Main success scenario 1. Get report duration from SQL Basic flow
2. Get process data and configuration
data from SQL
3. Create report from obtained data
4. Print report
9 Extensions Conditional /
branch
10 Special Requirements
11 Technology List
12 Frequency of occurrence Dependent on user
13 Miscellaneous
97

Table B. 6: FDUCD of the Monitor System
Use case Section Comment Meaning
1 Use case name Monitor system
2 Scope SCADA system System
3 Level User goal
4 Primary Actor Operator
5 Stakeholders and Interests
6 Preconditions Sensor values
7 Success Guarantee UI is updated
8 Main success scenario 1. Get sensor values from SQL server Basic flow
2. Update display
3. Wait
4. Jump to 1
9 Extensions Conditional /
branch
10 Special Requirements
11 Technology List
12 Frequency of occurrence 0.1 seconds
13 Miscellaneous
98

B3: Sequence Diagram
PowerUp initializes the system and is responsible for creating the SQL, Timer, Timer2, Read
Sensor, Control Pump, Control Algorithm, Configuration, Admin, Operator, Alarm System,
Monitoring, Reporting, and Printer objects.
Power Up
Read Sensor
Sensor
SQL
Timer
3 : rsid:create()
1 : sqlid:create()
2 : tid:create()
4 : Start()
5 : isensor=getNoOfSensors()
6 : isensor
7 *[i=1..isensor] : SensorArray[i]=create()
8 : sleep=getDelay()
sd Measurement loop
9 : sensor_s=getSensor[1...isensor]value()
10 : sensor_s
11 : sensor_v=convertSensor[1...isensor]value()
12 : UpdateSensorValue()
13 : sleep()
Figure B. 9: Sequence diagram of the Read sensor usecase
99

Power up Control Pump Control Algorithm Pump
SQL Timer
3 : cpid:create()
1 : caid:create()
2 : sqlid:create()
4 : ipump=getNoOfPumps()
5 : ipump
6 *[i=1..ipump] : PumpArray[i]:create()
7 : sleep=getDelay()
sd Pump update loop
8 : ui=getControllerOutput()
9 : ui
10 : control_v=convertControlleroutput[1...ipump]values()
11 : UpdatePump[1...ipump]signal()
12 : sleep()
Figure B. 10: Sequence diagram of the control pump usecase
100

Power up : Control Algorithm Read Sensor : Timer
: SQL
: Configuration File
2 : caid : create()
1 : tid : create()
3 : rsid : create()
4 : sqlid:create()
5 : start()
6 : cfid : create()
7 : sleep=getDelay()
sensor loop
8 : Check WAN()
9 *[WAN==true] : cp=getcontrollerparameters()
10 : cp
11 *[WAN==true] : sp=getsetpoint()
12 : sp
13 : log_cp()
14 : log_sp()
15 *[WAN==false] : cp=getcontrollerparameters()
16 : cp
17 *[WAN==false] : sp=getsetpoint()
19 : iVal=getValue()
18 : sp
20 : iVal
21 : ui=Computecontrolleroutput()
22 : log_ui()
23 [configTrigger == true] : cp=getcontrollerparameters()
24 : cp
25 [configTrigger == true] : sp=getsetpoint()
26 : sp
27 : log_cp()
28 : log_sp()
29 : sleep()
Figure B. 11: Sequence diagram of the Control Algorithm usecase
101

Power up : Admin
Configuration
: SQL
: Control Algorithm
1 : cid:create()
2 : sqlid:create()
4 : adid:create()
3 : caid:create()
5 : login()
6 *[login==valid] : allowAccess
7 *[login==invalid] : denyAccess
8 *[acknowledge change of parameters==false] : =retainOldParameters()
9 *[acknowledge change of parameters==true] : =updateWithnewParameters()
10 *[parameterschange==true] : =updateNewParameters()
11 *[parameterschange==true] : sendTrigger()
Figure B. 12: Sequence diagram of the Configuration usecase
102

Power Up
Alarm system SQL Operator
Admin
Timer2
1 : sqlid=create()
2 : oid:create()
3 : adid:create()
5 : asid:create()
4 : t2id:create()
6 : Start()
7 : sleep=getDelay()
8 : isensor=getNoOfSensors()
9 : isensor
10 : sensor_h_limit=get_sensor_high_limit()
11 : sensor_h_limit
12 : sensor_l_limit=get_sensor_low_limit()
13 : sensor_l_limit
sd Alarm_check_loop
14 : Sensor_v=get_sensor_values()
sd i to isensor loop
15 : Sensor_v
16 [sensor_l_limit>Sensor_v(i)] : create_low_alarm()
17 [sensor_h_limit

PowerUp
: Monitoring : SQL : Admin : Operator : Timer2
1 : sqlid=create()
2 : msid=create()
3 : adid=create()
4 : oid=create()
5 : t2id=create()
6 : start()
7 : sleep=getDelay()
8 : isensor=getNoOfSensors()
9 : sensor
sd Monitoring_loop
10 : sval=get_sensor_values()
11 : sval
12 : updateDisplay()
13 : updateDisplay()
14 : sleep()
Figure B. 14: Sequence diagram of the Monitor system usecase
104

PowerUp
: Reporting : SQL
: Printer
1 : sqlid=create()
2 : rid=create()
3 : prid=create()
4 : Start()
5 : did=get_duration()
6 : did
7 : pid=get_process_data()
8 : pid
9 : cid=get_configuration_data()
10 : cid
11 : generate_report()
12 : print_report()
Figure B. 15: Sequence diagram of the Report system usecase
105

B4: Class Diagram
Configuration File
+Configuration File()
+log_cp()
+log_sp()
+getcontrollerparameters()
+getsetpoint()
Configuration
+Configuration()
+login()
+retainOldParameters()
+updateWithnewParameters()
configTrigger
-cfid
-sleep
-cp
-sp
-iVal
-ui
create
Control Algorithm
+Control Algorithm()
+getControllerOutput()
+getDelay()
+CheckWAN()
+Computecontrolleroutput()
SQL
+SQL()
+getNoOfSensors()
+getNoOfPumps()
+getcontrollerparameters()
+getsetpoint()
+log_ui()
+updateNewParameters()
+UpdateSensorValue()
+get_sensor_high_limit()
+get_sensor_low_limit()
+get_sensor_values()
+get_new_sensor_high_limit()
+get_new_sensor_low_limit()
+get_duration()
+get_process_data()
+get_configuration_data()
Reporting
-did
-pid
-cid
+Reporting()
+generate_report()
Timer
+Timer()
+sleep()
Read Sensor
create
-isensor
-SensorArray
-sleep
-sensor_s
-sensor_v
+Read Sensor()
+getDelay()
+getValue()
create
create
create
create
create
-ipump
-PumpArray
-sleep
-ui
-control_v
Control Pump
+Control Pump()
+getDelay()
+update_ui()
+convertControlleroutputvalues()
Sensor
+Sensor()
+getSensorvalue()
+convertSensorvalue()
create
Printer
+Printer()
+print_report()
create
Power Up
-sqlid
-tid
-rsid
-cpid
-caid
-cid
-adid
-oid
-t2id
-asid
-msid
-rid
-prid
+main()
create
create
create
Admin
+Admin()
+UpdateDisplay()
Pump
+Pump()
+UpdatePumpsignal()
create
Alarm System
Timer2
+Timer2()
+sleep()
create
-sleep
-isensor
-sensor_h_limit
-sensor_l_limit
-Sensor_v
+Alarm System()
+getDelay()
+create_low_alarm()
+create_high_alarm()
create
Monitoring
-sleep
-isensor
-sval
+Monitoring()
+getDelay()
Operator
+Operator()
+UpdateDisplay()
Figure B. 16: Class diagram of the SCADA software application
106

B5: Object Diagram
Configuration File
+Configuration File()
+log_cp()
+log_sp()
+getcontrollerparameters()
+getsetpoint()
create
Configuration
+Configuration()
+login()
+retainOldParameters()
+updateWithnewParameters()
configTrigger
-cfid
-sleep
-cp
-sp
-iVal
-ui
Control Algorithm
+Control Algorithm()
+getControllerOutput()
+getDelay()
+CheckWAN()
+Computecontrolleroutput()
SQL
+SQL()
+getNoOfSensors()
+getNoOfPumps()
+getcontrollerparameters()
+getsetpoint()
+log_ui()
+updateNewParameters()
+UpdateSensorValue()
+get_sensor_high_limit()
+get_sensor_low_limit()
+get_sensor_values()
+get_new_sensor_high_limit()
+get_new_sensor_low_limit()
+get_duration()
+get_process_data()
+get_configuration_data()
Reporting
-did
-pid
-cid
+Reporting()
+generate_report()
Timer
+Timer()
+sleep()
Read Sensor
create
-isensor
-SensorArray
-sleep
-sensor_s
-sensor_v
+Read Sensor()
+getDelay()
+getValue()
create
create
create
create
create
-ipump
-PumpArray
-sleep
-ui
-control_v
Control Pump
+Control Pump()
+getDelay()
+update_ui()
+convertControlleroutputvalues()
Sensor
+Sensor()
+getSensorvalue()
+convertSensorvalue()
Sensor1
+getSensorvalue()
+convertSensorvalue()
create
Printer
+Printer()
+print_report()
Sensor2
+getSensorvalue()
+convertSensorvalue()
create
Power Up
-sqlid
-tid
-rsid
-cpid
-caid
-cid
-adid
-oid
-t2id
-asid
-msid
-rid
-prid
+main()
create
create
create
Admin
+Admin()
+UpdateDisplay()
Pump1
+UpdatePumpsignal()
Pump
+Pump()
+UpdatePumpsignal()
Pump2
+UpdatePumpsignal()
create
Alarm System
Timer2
+Timer2()
+sleep()
create
-sleep
-isensor
-sensor_h_limit
-sensor_l_limit
-Sensor_v
+Alarm System()
+getDelay()
+create_low_alarm()
+create_high_alarm()
create
Monitoring
-sleep
-isensor
-sval
+Monitoring()
+getDelay()
Operator
+Operator()
+UpdateDisplay()
Figure B. 17: Object diagram of the SCADA software application
107

Appendix C: Database script
--Create a database named SCADA:
USE master;
GO
CREATE DATABASE SCADA;
GO
USE SCADA;
GO
--Create the tables:
CREATE TABLE [Tag]
(
[TagId] [int] NOT NULL PRIMARY KEY IDENTITY (1, 1),
[TagName] [varchar] (10) NOT NULL,
[TagType] [varchar] (10) NOT NULL,
[TagDescription] [varchar] (50) NULL,
)
CREATE TABLE [Controller]
(
[ControllerId] [int] NOT NULL PRIMARY KEY IDENTITY (1, 1),
[ControllerName] [varchar] (20) NOT NULL,
[Setpoint] [float] NOT NULL,
[ControllerDescription] [varchar] (50) NULL,
)
CREATE TABLE [ControllerConfig]
(
[ControllerConfigId] [int] NOT NULL PRIMARY KEY IDENTITY (1, 1),
[ControllerId] [int] NOT NULL FOREIGN KEY REFERENCES [Controller]
([ControllerId]),
[GainKp] [float] NOT NULL,
[IntegralTi] [float] NOT NULL,
[DifferentialTd] [float] NOT NULL,
)
CREATE TABLE [TagController]
(
[ControllerId] [int] NOT NULL FOREIGN KEY REFERENCES [Controller]
([ControllerId]),
[TagId] [int] NOT NULL FOREIGN KEY REFERENCES [Tag] ([TagId]),
)
CREATE TABLE [UpdateFlag]
(
[FlagId] [int] NOT NULL PRIMARY KEY IDENTITY (1, 1),
[FlagName] [varchar] (20) NOT NULL,
[FlagState] [int] NOT NULL,
[FlagDescription] [varchar] (50) NULL,
)
CREATE TABLE [Task]
(
[TaskId] [int] NOT NULL PRIMARY KEY IDENTITY (1, 1),
[TaskName] [varchar] (20) NOT NULL,
[TaskType] [varchar] (20) NOT NULL,
[Task] [varchar] (20) NOT NULL,
[TaskDescription] [varchar] (50) NULL,
)
108

CREATE TABLE [TagTask]
(
[TagId] [int] NOT NULL FOREIGN KEY REFERENCES [Tag] ([TagId]),
[TaskId] [int] NOT NULL FOREIGN KEY REFERENCES [Task] ([TaskId]),
)
CREATE TABLE [TagValue]
(
[TagValueId] [int] NOT NULL PRIMARY KEY IDENTITY (1, 1),
[TagId] [int] NOT NULL FOREIGN KEY REFERENCES [Tag] ([TagId]),
[TagValue] [float] NOT NULL,
[Timestamp] [datetime] NOT NULL,
)
CREATE TABLE [Timer]
(
[TimerId] [int] NOT NULL PRIMARY KEY IDENTITY (1, 1),
[TimerName] [varchar] (20) NOT NULL,
[TimerValue] [float] NOT NULL,
[TimerDescription] [varchar] (50) NULL,
)
CREATE TABLE [Login]
(
[LoginId] [int] NOT NULL PRIMARY KEY IDENTITY (1, 1),
[UserName] [varchar] (20) NOT NULL,
[Password] [varchar] (20) NOT NULL,
[Administrator] [int] NOT NULL,
)
CREATE TABLE [AlarmConfig]
(
[AlarmConfigId] [int] NOT NULL PRIMARY KEY IDENTITY (1, 1),
[AlarmType] [varchar] (20) NOT NULL,
[HighAlarm] [float] NOT NULL,
[LowAlarm] [float] NOT NULL,
)
CREATE TABLE [Alarm]
(
[AlarmId] [int] NOT NULL PRIMARY KEY IDENTITY (1, 1),
[AlarmConfigId] [int] NOT NULL FOREIGN KEY REFERENCES [AlarmConfig]
([AlarmConfigId]),
[TagValueId] [int] NOT NULL FOREIGN KEY REFERENCES [TagValue]
([TagValueId]),
[AlarmActive] [int] NOT NULL,
[AlarmAcknowledge] [int] NOT NULL,
[AlarmDescription] [varchar] (50) NULL,
)
--Insert default values into the tables:
INSERT INTO UpdateFlag(FlagName, FlagState, FlagDescription)
VALUES ('ControlUpdate', '0', 'Update flag for the control application');
INSERT INTO Tag(TagName, TagType, TagDescription)
VALUES ('LCV01', 'Output', 'Three-way valve value (pump 1, tank 1 and 4)'),
('LCV02', 'Output', 'Three-way valve value (pump 2, tank 2 and
3)'),
('LCP01', 'Output', 'Control signal for pump 1 (tank 1 and 4)'),
('LCP02', 'Output', 'Control signal for pump 2 (tank 2 and 3)'),
('LCT01', 'Input', 'Level sensor value for tank 1'),
('LCT02', 'Input', 'Level sensor value for tank 2');
109

INSERT INTO TagValue(TagId, TagValue, Timestamp)
SELECT TagId, '1', GetDate() FROM Tag
WHERE TagName = 'LCV01';
INSERT INTO TagValue(TagId, TagValue, Timestamp)
SELECT TagId, '1', GetDate() FROM Tag
WHERE TagName = 'LCV02';
INSERT INTO TagValue(TagId, TagValue, Timestamp)
SELECT TagId, '0', GetDate() FROM Tag
WHERE TagName = 'LCP01';
INSERT INTO TagValue(TagId, TagValue, Timestamp)
SELECT TagId, '0', GetDate() FROM Tag
WHERE TagName = 'LCP02';
INSERT INTO TagValue(TagId, TagValue, Timestamp)
SELECT TagId, '0', GetDate() FROM Tag
WHERE TagName = 'LCT01';
INSERT INTO TagValue(TagId, TagValue, Timestamp)
SELECT TagId, '0', GetDate() FROM Tag
WHERE TagName = 'LCT02';
INSERT INTO Controller(ControllerName, Setpoint, ControllerDescription)
VALUES ('PID1', '10', 'PID controller for tank 1.'),
('PID2', '10', 'PID controller for tank 2.');
INSERT INTO ControllerConfig(ControllerId, GainKp, IntegralTi,
DifferentialTd)
SELECT ControllerId, '0.9', '5', '0' FROM Controller
WHERE ControllerName = 'PID1';
INSERT INTO ControllerConfig(ControllerId, GainKp, IntegralTi,
DifferentialTd)
SELECT ControllerId, '0.8', '4.1', '0' FROM Controller
WHERE ControllerName = 'PID2';
INSERT INTO TagController(ControllerId, TagId)
SELECT dbo.Controller.ControllerId, dbo.Tag.TagId
FROM dbo.Controller CROSS JOIN dbo.Tag
WHERE (dbo.Controller.ControllerName = 'PID1' AND dbo.Tag.TagName =
'LCV01');
INSERT INTO TagController(ControllerId, TagId)
SELECT dbo.Controller.ControllerId, dbo.Tag.TagId
FROM dbo.Controller CROSS JOIN dbo.Tag
WHERE (dbo.Controller.ControllerName = 'PID2' AND dbo.Tag.TagName =
'LCV02');
INSERT INTO TagController(ControllerId, TagId)
SELECT dbo.Controller.ControllerId, dbo.Tag.TagId
FROM dbo.Controller CROSS JOIN dbo.Tag
WHERE (dbo.Controller.ControllerName = 'PID1' AND dbo.Tag.TagName =
'LCP01');
INSERT INTO TagController(ControllerId, TagId)
SELECT dbo.Controller.ControllerId, dbo.Tag.TagId
FROM dbo.Controller CROSS JOIN dbo.Tag
WHERE (dbo.Controller.ControllerName = 'PID2' AND dbo.Tag.TagName =
'LCP02');
INSERT INTO TagController(ControllerId, TagId)
110

SELECT dbo.Controller.ControllerId, dbo.Tag.TagId
FROM dbo.Controller CROSS JOIN dbo.Tag
WHERE (dbo.Controller.ControllerName = 'PID1' AND dbo.Tag.TagName =
'LCT01');
INSERT INTO TagController(ControllerId, TagId)
SELECT dbo.Controller.ControllerId, dbo.Tag.TagId
FROM dbo.Controller CROSS JOIN dbo.Tag
WHERE (dbo.Controller.ControllerName = 'PID2' AND dbo.Tag.TagName =
'LCT02');
INSERT INTO Task(TaskName, TaskType, Task, TaskDescription)
VALUES ('DAQ1Input', 'Input', 'SCADAinput1', 'Input task for DAQ1'),
('DAQ1Output', 'Output', 'SCADAoutput1', 'Output task for DAQ1'),
('DAQ2Input', 'Input', 'SCADAinput2', 'Input task for DAQ2'),
('DAQ2Output', 'Output', 'SCADAoutput2', 'Output task for DAQ2');
INSERT TagTask(TagId,TaskId)
SELECT dbo.Tag.TagId, dbo.Task.TaskId
FROM
dbo.Tag CROSS JOIN dbo.Task
WHERE (dbo.Tag.TagName = 'LCV01') AND (dbo.Task.TaskName =
'DAQ1Output');
INSERT TagTask(TagId,TaskId)
SELECT dbo.Tag.TagId, dbo.Task.TaskId
FROM
dbo.Tag CROSS JOIN dbo.Task
WHERE (dbo.Tag.TagName = 'LCV02') AND (dbo.Task.TaskName =
'DAQ2Output');
INSERT TagTask(TagId,TaskId)
SELECT dbo.Tag.TagId, dbo.Task.TaskId
FROM
dbo.Tag CROSS JOIN dbo.Task
WHERE (dbo.Tag.TagName = 'LCP01') AND (dbo.Task.TaskName =
'DAQ1Output');
INSERT TagTask(TagId,TaskId)
SELECT dbo.Tag.TagId, dbo.Task.TaskId
FROM
dbo.Tag CROSS JOIN dbo.Task
WHERE (dbo.Tag.TagName = 'LCP02') AND (dbo.Task.TaskName =
'DAQ2Output');
INSERT TagTask(TagId,TaskId)
SELECT dbo.Tag.TagId, dbo.Task.TaskId
FROM
dbo.Tag CROSS JOIN dbo.Task
WHERE (dbo.Tag.TagName = 'LCT01') AND (dbo.Task.TaskName =
'DAQ1Input');
INSERT TagTask(TagId,TaskId)
SELECT dbo.Tag.TagId, dbo.Task.TaskId
FROM
dbo.Tag CROSS JOIN dbo.Task
WHERE (dbo.Tag.TagName = 'LCT02') AND (dbo.Task.TaskName =
'DAQ2Input');
INSERT INTO Timer(TimerName, TimerValue, TimerDescription)
VALUES ('ControlTimer1', '100', 'How fast the control application should
run.'),
('ControlTimer2', '1000', 'How fast the control app updates the
database');
INSERT INTO Login(UserName, Password, Administrator)
VALUES ('Administrator','Administrator','1'),
('Operator','Operator','0');
111

--Create the database procedures:
GO
CREATE PROCEDURE UpdateTagValues
@Control1 DECIMAL(10,3), @Control2 DECIMAL(10,3),@Sensor1
DECIMAL(10,3),@Sensor2 DECIMAL(10,3)
AS
SET NOCOUNT ON;
UPDATE TagValue
SET TagValue = @Control1
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCP01');
UPDATE TagValue
SET TagValue = @Control2
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCP02');
UPDATE TagValue
SET TagValue = @Sensor1
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCT01');
UPDATE TagValue
SET TagValue = @Sensor2
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCT02');
SELECT FlagState from UpdateFlag
WHERE FlagName = 'ControlUpdate';
UPDATE UpdateFlag
SET FlagState = 0
WHERE FlagName = 'ControlUpdate' AND FlagState = 1;
SET NOCOUNT OFF;
GO
CREATE PROCEDURE UpdateConfiguration
@ReadTask1 CHAR(20),@WriteTask1 CHAR(20),@ReadTask2 CHAR(20),@WriteTask2
CHAR(20),
@Kp1 DECIMAL(10,3), @Ti1 DECIMAL(10,3),@Kp2 DECIMAL(10,3),@Ti2
DECIMAL(10,3),@Timer1 DECIMAL(10,3),@Timer2 DECIMAL(10,3),
@Setpoint1 DECIMAL(10,3),@Setpoint2 DECIMAL(10,3),@Valve1
DECIMAL(10,3),@Valve2 DECIMAL(10,3)
AS
SET NOCOUNT ON;
UPDATE Task
SET Task = @ReadTask1
WHERE TaskName = 'DAQ1Input';
UPDATE Task
SET Task = @WriteTask1
WHERE TaskName = 'DAQ1Output';
UPDATE Task
SET Task = @ReadTask2
WHERE TaskName = 'DAQ2Input';
112

UPDATE Task
SET Task = @WriteTask2
WHERE TaskName = 'DAQ2Output';
UPDATE ControllerConfig
SET GainKp = @Kp1, IntegralTi = @Ti1
FROM
dbo.Controller INNER JOIN
dbo.ControllerConfig ON dbo.Controller.ControllerId =
dbo.ControllerConfig.ControllerId
WHERE (dbo.Controller.ControllerName = 'PID1');
UPDATE ControllerConfig
SET GainKp = @Kp2, IntegralTi = @Ti2
FROM
dbo.Controller INNER JOIN
dbo.ControllerConfig ON dbo.Controller.ControllerId =
dbo.ControllerConfig.ControllerId
WHERE (dbo.Controller.ControllerName = 'PID2');
UPDATE Timer
SET TimerValue = @Timer1
WHERE TimerName = 'ControlTimer1';
UPDATE Timer
SET TimerValue = @Timer2
WHERE TimerName = 'ControlTimer2';
UPDATE Controller
SET Setpoint = @Setpoint1
WHERE ControllerName = 'PID1';
UPDATE Controller
SET Setpoint = @Setpoint2
WHERE ControllerName = 'PID2';
UPDATE TagValue
SET TagValue = @Valve1
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCV01');
UPDATE TagValue
SET TagValue = @Valve2
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCV02');
SET NOCOUNT OFF;
GO
--Create the database views:
CREATE VIEW Tasks(ReadTask1,WriteTask1,ReadTask2,WriteTask2)
AS
SELECT
(SELECT Task FROM Task WHERE TaskName='DAQ1Input'),
(SELECT Task FROM Task WHERE TaskName='DAQ1Output'),
(SELECT Task FROM Task WHERE TaskName='DAQ2Input'),
(SELECT Task FROM Task WHERE TaskName='DAQ2Output')
FROM Task
WHERE TaskName='DAQ1Input';
GO
CREATE VIEW Valves(Valve1,Valve2)
113

AS
SELECT
(SELECT TagValue
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCV01')),
(SELECT TagValue
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCV02'))
FROM Tag
WHERE TagName = 'LCV01';
GO
CREATE VIEW Timers(Timer1,Timer2)
AS
SELECT
(SELECT TimerValue FROM Timer WHERE TimerName='ControlTimer1'),
(SELECT TimerValue FROM Timer WHERE TimerName='ControlTimer2')
FROM Timer
WHERE TimerName='ControlTimer1';
GO
CREATE VIEW Setpoints(Setpoint1,Setpoint2)
AS
SELECT
(SELECT Setpoint FROM Controller WHERE ControllerName='PID1'),
(SELECT Setpoint FROM Controller WHERE ControllerName='PID2')
FROM Controller
WHERE ControllerName='PID1';
GO
CREATE VIEW PID1
AS
SELECT GainKp, IntegralTi
FROM dbo.Controller INNER JOIN
dbo.ControllerConfig ON dbo.Controller.ControllerId =
dbo.ControllerConfig.ControllerId
WHERE (dbo.Controller.ControllerName = 'PID1');
GO
CREATE VIEW PID2
AS
SELECT GainKp, IntegralTi
FROM dbo.Controller INNER JOIN
dbo.ControllerConfig ON dbo.Controller.ControllerId =
dbo.ControllerConfig.ControllerId
WHERE (dbo.Controller.ControllerName = 'PID2');
GO
CREATE VIEW ConfigView
AS
SELECT dbo.Tasks.ReadTask1, dbo.Tasks.WriteTask1, dbo.Tasks.ReadTask2,
dbo.Tasks.WriteTask2, dbo.PID1.GainKp AS Kp1, dbo.PID1.IntegralTi AS Ti1,
dbo.PID2.GainKp AS Kp2, dbo.PID2.IntegralTi AS Ti2,
dbo.Timers.Timer1, dbo.Timers.Timer2, dbo.Setpoints.Setpoint1,
dbo.Setpoints.Setpoint2, dbo.Valves.Valve1,
dbo.Valves.Valve2
FROM dbo.PID1 CROSS JOIN dbo.PID2 CROSS JOIN dbo.Setpoints CROSS JOIN
dbo.Tasks CROSS JOIN
dbo.Timers CROSS JOIN dbo.Valves
GO
114

CREATE VIEW MonitorTags(Valve1,Valve2,Pump1,Pump2,Sensor1,Sensor2)
AS
SELECT
(SELECT TagValue
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCV01')),
(SELECT TagValue
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCV02')),
(SELECT TagValue
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCP01')),
(SELECT TagValue
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCP02')),
(SELECT TagValue
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCT01')),
(SELECT TagValue
FROM dbo.Tag INNER JOIN dbo.TagValue ON dbo.Tag.TagId =
dbo.TagValue.TagId
WHERE (dbo.Tag.TagName = 'LCT02'))
FROM Tag
WHERE TagName = 'LCV01';
GO
CREATE VIEW
MonitoringView(Valve1,Valve2,Pump1,Pump2,Sensor1,Sensor2,Setpoint1,Setpoint
2)
AS
SELECT dbo.MonitorTags.Valve1, dbo.MonitorTags.Valve2,
dbo.MonitorTags.Pump1, dbo.MonitorTags.Pump2,
dbo.MonitorTags.Sensor1,
dbo.MonitorTags.Sensor2,dbo.Setpoints.Setpoint1, dbo.Setpoints.Setpoint2
FROM dbo.MonitorTags CROSS JOIN dbo.Setpoints
GO
--Create the database trigger:
CREATE TRIGGER UpdateCheck1 ON Controller
FOR UPDATE
AS
SET NOCOUNT ON;
UPDATE UpdateFlag
SET FlagState='1' WHERE FlagName = 'ControlUpdate'
SET NOCOUNT OFF;
GO
115

Appendix D: Project code and deployment files.
116