DESIGN AND IMPEMENTATION OF

WEB BASED SCADA SYSTEM

A Thesis
Submitted to the College of Engineering
of Nahrain University in Partial Fulfillment
of the Requirements for the Degree of
Master of Science
in
Computer Engineering

by

AHMAD YASSEEN KHATHAIR

AL-OBAIDY
(B.Sc. 2003)

Jumada Al-Oula

1427

June

2006

Certification

I certify that this thesis entitled Design and Implementation of Web

based SCADA System was prepared by Ahmad Yasseen Khathair AlObaidy, under my supervision at Nahrain University, College of Engineering,
in partial fulfillment of the requirements for the degree of Master of Science
in Computer Engineering.

Signature:

Name

: Dr. Firas Abdullah Thweny Al-Saidi

(Supervisor)

Date

Signature:

Name: Asst. Dr. Prof. Mohammed Z. Al-Faiz

(Head of Department)

Date :

Certification
We certify, as an examining committee, that we have read this thesis
entitled Design and Implementation of Web based SCADA System,
examined the student (Ahmad Yasseen Khathair Al-Obaidy) in its content
and found it meets the standard of thesis for the degree of Master of Science
in Computer Engineering.

Signature:
Name:
Date:

Signature:
Dr. Firas Abdullah
Thweny Al-Saidi
(Supervisor)
/ /

Signature:
Name:
Date:

Name:
Date:

Dr. Noaman M. Noaman

(Member)
/

Signature:
Asst. Prof. Dr. Sufyan T.
Name:
Faraj
(Member)
/ /
Date:

Prof. Dr. Ali Abbas Ali

(Chairman)
/

Approval of the College of Engineering

Signature:
Name:
Date:

Prof. Dr. Fawzi M. Al-Naima

(Dean)
/ /

Abstract

Computer-based Supervisory Control and Data Acquisition (SCADA)

systems have evolved over the past 40 years, from standalone,
compartmentalized

operations

into

networked

architectures

that

communicate across large distances. In addition, their implementations

have migrated from custom hardware and software to standard hardware
and software platforms.
On the other hand, the World Wide Web (WWW) has become a
convenient way to access information on the net because the Web browser
integrates different network services into a common easily accessible user
interface. These features coupled with low investment cost are especially
suited for exchanging information of the SCADA system. This thesis tires
to develop an approach for building Web-based SCADA system which is
implemented based on the client/server architecture. It also addresses the
problems concerning security aspects.
The software developed in this thesis tried to route the design of
Web-based SCADA system by supporting all the implementation aspects
for two case studies; the first one is concerned with controlling water level
of a network of dams. This case study discusses and implements the main
aspect of the problem from the water level measurement, logging readings
to server, getting desired levels of water, controlling the gate of the dam,
along with monitoring the logged readings, all with security aspects in
mind. The second case study is issued for monitoring the network traffic on
a set of Very Small Aperture Terminal (VSAT) modems.
The whole project was implemented using open source software and
frameworks. Linux was used as the operating system for the server and the

clients, PHP was selected as programming language for the server side
whereas Perl and C for the client side. MySQL was used as database server.
Both of the implemented systems were tested successfully in many
different environments, to make sure of its validity and testing its
functionality. The environments ranged from Local Area Network (LAN)
to Virtual Private Network (VPN).

II

List of Contents
Contents

Page

Abstract
List of Contents

I
III

List of Abbreviations

VI

Chapter 1: Introduction
1.1 SCADA Overview

1.2 SCADA System Architecture

1.2.1 Field Data Interface Devices

1.2.2 Communications Network

1.2.3 Master Terminal Unit

1.2.4 Operator Workstations and Software Components

1.3 Web-based SCADA System

1.4 Introduction to the Open Source Concepts

10

1.5 Literature Survey

12

1.6 Work Objectives

13

1.7 Thesis Layout

14

Chapter 2: Distributed Web Applications and Database

Concepts
2.1 Overview

15

2.2 Types of Applications

16

2.2.1 Single-tier Applications

16

2.2.2 Two-tier Applications

17

2.2.3 Multi-tier Applications

18

2.3 Elements of a Distributed Application

19

2.3.1 Presentation Tier

21

2.3.2 Middle Tier

22

2.3.3 Data Tier

24

2.4 Introduction to Database Systems

25

III

2.4.1 Introduction to MySQL

26

2.4.2 Database Concepts

27

2.5 Security Aspects of Web-Based SCADA System

28

2.5.1 Data Protection

29

2.5.2 Authentication

32

2.7.3 Authorization

33

Chapter 3: Case Study One: Water Level Control

3.1 Introduction

34

3.2 The Operation of the Overall System

35

3.3 Master Terminal Unit

36

3.3.1 The System Database

37

3.3.2 The RTU Service Provider

39

3.3.3 HMI Provider

42

3.3.4 MTU System Requirements

46

3.4 Remote Terminal Unit

46

3.4.1 Field Data Interface Device

46

3.4.2 Parallel Port Interface

46

3.4.3 Water Level Sensor

48

3.4.4 Dam Gate Actuator

52

3.4.5 Programming the RTU

54

3.4.6 Perl

54

3.4.7 Local Administration Interface

54

3.4.8 RTU Automation Software

55

3.4.9 RTU System Requirements

59

3.5 Operator Related Instructions for WLC

3.5.1 MTU Administrator
3.5.2 RTU Administrator
3.6 Tested Environments for the WLC
3.6.1 Local Area Network
3.6.2 Global Internet
3.6.3 VPN Network

IV

60
61
68
68
69
70
75

Chapter 4: Case Study Two: VSAT Modems Monitoring

System
4.1 Introduction

78

4.2 System Overall Operation

78

4.3 Master Terminal Unit

79

5.3.1 The System Database

79

5.3.2 RTU Service Provider

80

5.3.3 HMI Provider

82

4.4 Implemented RTU

83

5.4.1 Cross Compilation

84

5.4.2 Microperl

85

5.4.3 Traffic Measurement

85

5.4.4 The Implementation

86

4.5 Operator Related Instructions for VMS

4.5.1 MTU Administrator
4.5.2 RTU Administrator
4.6 Tested Environments for VMS

87
88
96
96

Chapter 5: Conclusions and Future Work

5.1 Conclusions

98

5.2 Future Work

99

References

101

List of Abbreviations
ANSI

American National Standards Institute

ARM

Advanced RSIC Machine

COTS

Commercial Off-The-Shelf

CPAN

Comprehensive Perl Archive Network

CPU

Central Processing Unit

DBMS

Database Management System

DoS

Denial of Service

GCC

GNU C Compiler

GHz

Gigahertz

GIS

Geographical Information System

GPL

GNU Public License

GPRS

General Packet Radio Service

GPS

Global Positioning System

GSM

Global Services Mobile Communications

GUI

Graphical User Interface

HMI

Human Machine Interface

HTTP

Hyper Text Transfer Protocol

I/O

Input/Output

ICMP

Internet Control Message Protocol

IDE

Integrated Development Environment

IEEE

Institute of Electrical and Electronics Engineers

IP

Internet Protocol

ISDN

Integrated Services Digital Network

ISO

International Organization for Standardization

ISP

Internet Service Provider

VI

IT

Information Technology

JAWS

Java Web Start

JMS

Java Messaging Service

LAI

Local Administration Interface

LAN

Local Area Network

LED

Light Emitting Diodes

MAC

Medium Access Control

MD5

Message Digest 5

MMI

Man Machine Interface

MSL

Mean Sea Level

MTU

Master Terminal Unit

NAT

Network Address Translation

OS

Operating System

PBX

Private Branch Exchange

PC

Personal Computer

PLC

Programmable Logic Controller

PSN

Public Switched Network

RAS

RTU Automation Software

RDBMS

Relational Database Management System

RISC

Reduced Instruction Set Computer

RSP

RTU Service Provider

RTU

Remote Terminal Unit

SCADA

Supervisory Control and Data Acquisition

SHA-1

Secure Hash Algorithm

SMS

Short Message Service

SMTP

Simple Mail Transfer Protocol

SQL

Structured Query Language

VII

SSL

Secured Socket Layer

TCO

Total Cost of Ownership

TCP/IP

Transmission Control Protocol/Internet Protocol

UART

Universal Asynchronous Receiver Transmitters

UI

User Interface

URL

Universal Resource Locator

VLAN

Virtual LAN

VMS

VSAT modems Monitoring System

VPN

Virtual Private Network

VSAT

Very Small Aperture Terminal

WAN

Wide Area Network

WLC

Water Level Control

XML

eXtensible Markup Language

VIII

CHAPTER ONE

Introduction

1.1 SCADA Overview

SCADA stands for Supervisory Control and Data Acquisition [1]. SCADA
systems are used to monitor and control a plant or equipment in industries
such as telecommunications, water and waste control, energy, oil and gas
refining and transportation. Such systems encompass the transfer of data
between a SCADA central host computer, also called Master Terminal Unit
(MTU), a number of Remote Terminal Units (RTUs), the central host and the
operator terminals. A SCADA system gathers information (such as where a
leak on a pipeline has occurred), transfers the information back to a central
site, then alerts the operator station that a leak has occurred, carrying out
necessary analysis and control, such as determining if the leak is critical, and
displaying the information in a logical and organized fashion. These systems
can be relatively simple, such as one that monitors environmental conditions
of a small office building, or very complex, such as a system that monitors all
the activity in a nuclear power plant or the activity of a municipal water
system. Traditionally, SCADA systems have made use of the Public Switched
Network (PSN) for monitoring purposes. Today many systems are monitored
using the infrastructure of the corporate Local Area Network (LAN)/Wide
Area Network (WAN) or the global Internet. Wireless technologies are now
being widely deployed for purposes of monitoring [2][3].

1.2 SCADA System Architecture

Specific terminology is associated with the components of SCADA systems.

These SCADA elements are defined as follows:
Operator: Human operator who monitors the SCADA system and
performs supervisory control functions for the remote plant operations.
Human machine interface (HMI): Presents data to the operator and
provides for control inputs in a variety of formats, including graphics,
schematics, windows, pull-down menus, touch-screens, and so on.
Master terminal unit (MTU): Equivalent to a master unit in a master/
slave architecture. The MTU presents data to the operator through the
HMI, gathers data from the distant site, and transmits control signals to
the remote site. The transmission rate of data between the MTU and the
remote site is relatively low and the control method is usually open
loop because of possible time delays or data flow interruptions.
Communications means: Communication method between the MTU
and remote controllers. Communication can be through the Internet,
wireless, wired networks, or the switched public telephone network.
Remote terminal unit (RTU): Functions as a slave in the master/slave
architecture. It sends control signals to the device under control,
acquires data from these devices, and transmits the data to the MTU.
An RTU may be a PLC. The data rate between the RTU and the
controlled device is relatively high and the control method is usually
closed loop [3].
Figure 1.1 shows a typical SCADA system. Each of the showed system
components will be discussed in detail in the next sections.

Figure 1.1 Typical SCADA System

1.2.1 Field Data Interface Devices

Field data interface devices form the "eyes and ears" of a SCADA system.
Devices such as reservoir level meters, water flow meters, valve position
transmitters, temperature transmitters, power consumption meters, and

pressure meters all provide information that can tell an experienced operator
how well a water distribution system is performing. In addition, equipment
such as electric valve actuators, motor control switchboards, and electronic
chemical dosing facilities can be used to form the "hands" of the SCADA
system and assist in automating the process of distributing water [2].
However, before any automation or remote monitoring can be
achieved, the information that is passed to and from the field data interface
devices must be converted to a form that is compatible with the language of
the SCADA system. To achieve this, some form of electronic field data
interface is required. RTUs provide this interface. They are primarily used to
convert electronic signals received from field interface devices into the
language (known as the communication protocol) used to transmit the data
over a communication channel [2].
The instructions for the automation of field data interface devices, such
as pump control logic, are usually stored locally. This is largely due to the
limited bandwidth typical of communications links between the SCADA
central host computer and the field data interface devices [2].

1.2.2 Communications Network

The communications network is intended to provide the means by which data
can be transferred between the central host computer servers and the fieldbased RTUs. The Communication Network refers to the equipment needed to
transfer data to and from different sites. The medium used can either be cable,
telephone or radio [2].
The use of cable is usually implemented in a factory. This is not
practical for systems covering large geographical areas because of the high
cost of the cables, conduits and the extensive labor in installing them. The use

of telephone lines (i.e., leased or dial-up) is a more economical solution for

systems with large coverage. The leased line is used for systems requiring online connection with the remote stations. This is expensive since one
telephone line will be needed per site. Dial-up lines can be used on systems
requiring updates at regular intervals (e.g., hourly updates). Here ordinary
telephone lines can be used. The host can dial a particular number of a remote
site to get the readings and send commands [2].
Remote sites are usually not accessible by telephone lines. The use of
radio offers an economical solution. Radio modems are used to connect the
remote sites to the host. An on-line operation can also be implemented on the
radio system. For locations where a direct radio link cannot be established, a
radio repeater is used to link these sites [2].
Historically, SCADA networks have been dedicated networks;
however, with the increased deployment of office LANs, WANs and even the
global Internet as a solution for interoffice computer networking, there exists
the possibility to integrate SCADA LANs into everyday office computer
networks [2].
The foremost advantage of this arrangement is that there is no need to
invest in a separate computer network for SCADA operator terminals. In
addition, there is an easy path to integrating SCADA data with existing office
applications, such as spreadsheets, work management systems, data history
databases and Geographic Information System (GIS) [2].

1.2.3 Master Terminal Unit

The central host computer or Master Terminal Unit (MTU) is most often a
single computer or a network of computer servers that provide a HMI to the
SCADA system. MTU process the information received from and sent to the

RTU sites and present it to human operators in a form that the operators can
work with. Operator terminals are connected to the MTU by a LAN/WAN so
that the viewing screens and associated data can be displayed for the
operators. Recent SCADA systems are able to offer high resolution computer
graphics to display a graphical user interface or mimic screen of the site or
water supply network in question. Historically, SCADA vendors offered
proprietary hardware, operating systems, and software that was largely
incompatible with other vendors' SCADA systems. Expanding the system
required a further contract with the original SCADA vendor. The MTU
computer network was physically separated from any office-computing
domain [2].
However, with the increased use of the personal computer, computer
networking has become commonplace in the office and as a result, SCADA
systems are now available that can networked with office-based personal
computers. Indeed, many of today's SCADA systems can reside on computer
servers that are identical to those servers and computers used for traditional
office applications. This has opened a range of possibilities for the linking of
SCADA systems to office-based applications such as GIS systems, hydraulic
modeling software, drawing management systems, work scheduling systems,
and information databases [2].

1.2.4 Operator Workstations and Software Components

Operator workstations are most often computer terminals that are networked
with the MTU. The MTU acts as a server for the SCADA application, and the
operator terminals are clients that request and send information to the MTU
computer based on the request and action of the operators [2].

An important aspect of every SCADA system is the computer software

used within the system. The most obvious software component is the operator
interface or HMI package; however, software of some form is used in all
levels of a SCADA system. Depending on the size and nature of the SCADA
application, software can be a significant cost item when developing,
maintaining, and expanding a SCADA system. When software is well
defined, designed, written, checked, and tested, a successful SCADA system
will likely be produced. Poor performances in any of these project phases
would easily cause a SCADA project failure [2].
Many SCADA systems employ commercial proprietary software upon
which the SCADA system is developed. The proprietary software often is
configured for a specific hardware platform and may not interface with the
software or hardware produced by competing vendors. A wide range of
commercial off-the-shelf (COTS) software products also are available, some
of which may suit the required application. COTS software usually is more
flexible, and will interface with different types of hardware and software.
Generally, the focus of proprietary software is on processes and control
functionality, while COTS software emphasizes compatibility with a variety
of equipment and instrumentation. It is therefore important to ensure that
adequate planning is undertaken to select the software systems appropriate to
any new SCADA system [2].
Software products typically used within a SCADA system are as follows:
Central host computer operating system: Software used to control the
central host computer hardware. The software can be based on
Linux/UNIX or other popular operating systems.
Operator terminal operating system: Software used to control the
operators computers hardware. The software is usually the same as the
central host computer operating system. This software, along with that

for the central host computer, usually contributes to the networking of

the central host and the operator terminals.
MTU application: Software that handles the transmittal and reception
of data to and from the RTUs and the MTU. The software also provides
the graphical user interface which offers site mimic screens, alarm
pages, trend pages, and control functions.
Operator terminal application: Application that enables users to access
information available on the central host computer application. It is
usually a subset of the software used on the central host computers.
Communications protocol drivers: Software that is usually based within
the central host and the RTUs, and is required to control the translation
and interpretation of the data between ends of the communications
links in the system. The protocol drivers prepare the data for use either
at the field devices or the central host end of the system.
Communications network management software: Software required to
control the communications network and to allow the communications
networks themselves to be monitored for performance and failures.
RTU automation software: Software that allows engineering staff to
configure and maintain the application housed within the RTUs. Most
often this includes the local automation application and any data
processing tasks that are performed within the RTU [2].
The preceding software products provide the building blocks for the
application-specific software, which must be defined, designed, written,
tested, and deployed for each SCADA system.

1.3 Web-based SCADA System

Nowadays, Internet is playing an important role in different domains. It had
gained a lot of researches and investments. Hundreds of billions of dollars had
been spent on the infrastructure and the backbone of the Internet; as a result,
Internet now is covering almost the entire planet. This made the Internet an
excellent choice to transfer any kind of data between any two or more points
[4].
Other hundreds of billions had been spent on developing tools,
framework, platforms, protocols and computer languages to make the
development of Internet applications easier and less expensive. Average
programmers could now develop Internet applications easily [4].
These reasons are strong enough to adopt the Internet and its
technologies in any type of distributed applications. SCADA makes no
exception on this [4].
Web-based SCADA System makes use of the Internet and Hypertext
Transfer Protocol (HTTP) and other Web technologies as a communication
layer of the system. It also uses development tools, framework, platforms and
computer languages used to be used by regular Internet applications as
development environment of SCADA application [5][4].
Web-based SCADA system uses the Internet to transfer data between
the RTUs and the MTU and/or between the operators workstations and the
MTU. This will reduce the cost of the installation of the SCADA network if
compared with installing a dedicated network for it [5].
It also uses the Internet browser programs such as Mozilla Firefox,
Netscape Navigator or Microsoft Internet Explorer as Graphical User
Interface (GUI) for the operators HMI. This would give all the benefits of
browser-based systems, such as simplifying the installation process of the

client side of the SCADA systems and also enable the users to access the
system using wide range of platforms, as the browsers is now available in
most of the modern operating systems.
Web-based SCADA system has many advantages including: [5]
Using the Client/Server n-tier platforms and development tools to
develop the Web-based SCADA system will get the development cost
and time to the minimum.
Using the Infrastructure of the Internet or the corporate intranet will get
the deployment cost to the minimum.
Increase distance, data sharing and data provision for monitoring and
control systems.
Enabling collaboration between skilled plant managers situated in
geographically diverse locations.
Enabling the business to relocate the physical location of plant
management staff easily in response to business needs.
For the educational and researching purposes; the risk involving in real
laboratory may be avoided by doing the dangerous experiments
remotely [4][5].

1.4 Introduction to the Open Source Concepts

In this project, all the operating systems, programming languages and servers
are chosen from the open source world. This section introduces the open
source concept and shows the reasons of adopting it.
Open source refers to a program in which the source code is available
to the general public for use and/or modification from its original design free
of charge, i.e., open. Open source code is typically created as a collaborative

10

effort in which programmers improve upon the code and share the changes
within the community. Open source sprouted in the technological community
as a response to proprietary software owned by corporations [6].
The following are some of the advantages of using open source software:
Lower software costs: Open source solutions generally require no
licensing fees. The logical extension is no maintenance fees. The only
expenditures are for media, documentation, and support, if required.
Simplified license management: The software is obtained once and
installed as many times and in as many locations as needed. Theres no
need to count, track, or monitor for license compliance.
Lower hardware costs: In general, Linux and open source solutions are
elegantly compact and portable, and as a result require less hardware
power to accomplish the same tasks as on conventional servers
(Windows, Solaris) or workstations. The result is the task is done using
less expensive or older hardware.
Scaling/consolidation potential: Again, Linux and open source applications
and services can often scale considerably. Multiple options for load
balancing, clustering, and open source applications, such as database and
e-mail, give organizations the ability to scale up for new growth or
consolidate to do more with less.
Great support: Support is available for open source, often superior to
proprietary solutions. First, open source support is freely available and
accessible through the online community via the Internet. And second,
many technical companies (not the least of which is Novell) are now
supporting open source with free online and multiple levels of paid
support. All open source solutions distributed by Novell are included in
support and maintenance contracts.

11

 Escape vendor lock-in: Frustration with vendor lock-in is a reality for all
IT managers. In addition to ongoing license fees, there is lack of
portability and the inability to customize software to meet specific needs.
Open source exists as a declaration of freedom of choice.
Unified management: Specific open source technologies such as Common
Information Model (CIM) and Web Based Enterprise Management
(WBEM) provide the capability to integrate or consolidate server, service,
application, and workstation management for powerful administration.
Quality software: Evidences and researches indicate that open source
software are high quality products. They are comparable to the peer
commercial ones, plus the fact that source code is available for everyone
to see, analyze and enhance, tend to drive excellence in design and
efficiency in coding [6][7].

1.5 Literature Survey

There are several published literatures and papers about Web-based SCADA,
and here is a descriptive review to some of them:
B. Qiu and H. B. Gooi published in 1999 a paper entitled (Web-Based
SCADA Display Systems (WSDS) for Access via Internet). This
paper has described a Web-based SCADA display system designed for
the WWW. The object-oriented design approach and the client/server
module allow the user great flexibility to dynamically interact with the
SCADA system [8].
Mike Clayton EP et al. published in 2002 a paper entitled (A SCADAWeb Interconnection with TCP in Java). In this paper the basic

12

concepts for a TCP Java overall structure to implement an interaction

between the SCADA systems and Web servers, has been discussed [4].
Kostas Kalaitzakis et al. published in 2003 (Development of a data
acquisition system for remote monitoring of renewable energy
systems). The development of a data acquisition system for remote
monitoring the operation of a plant is analyzed in this paper. It is based
on Client / Server architecture and it does not require a physical
connection, e.g. through network, serial communication port or
standard interface such as the IEEE-488 [9].
Andrew K. Wright et al. published in 2004 a paper entitled (LowLatency Cryptographic Protection for SCADA Communications).
This paper had discussed the aspect of security of SCADA systems and
how the security enforcement in the system affects the overall
performance and the real-time requirements [10].

1.6 Work Objectives

The main objective to be achieved in this project is to build a software and
hardware infrastructure for Web-based SCADA system.
The second objective is to show how to implement such systems using
open source platform and frameworks. This will give many advantages in the
area of cost and flexibility.

13

1.7 Thesis Layout

The thesis is structured into five chapters.
Chapter Two gives an overview about Web applications development.
It also introduces the concepts of databases.
The thesis implements two case studies to illustrate the Web-based
SCADA systems. The development procedures and details of the software
and hardware of the first case study are illustrated in details in Chapter Three.
Chapter Four describes the second case study. The chapter illustrates
the implementation of the server and client sides.
Chapter Three and Four also give an operator related instructions to use
both of the systems implemented in the case studies, it also shows the results
obtained from the developed software and the environments it was run and
tested into.
Finally, conclusions gained from the thesis with some ideas for the
future work are listed in Chapter Five.

14

CHAPTER TWO

Distributed Web Applications and

Database Concepts

2.1 Overview
In Web-based SCADA systems, the MTU is implemented as a distributed
web application. For that reason; it is very important to introduce the basic
concepts of this type of applications. These concepts are illustrated here in
this chapter.
An application is a computer program that solves a particular problem
or related set of problems. A simple application runs in a single process space
and often loads in utility, or helper, functions through dynamic-link libraries,
which helps the application to achieve its task.
A typical application that interacts with a user consists of three
elements: presentation, application logic, and data services. Each of these
elements (or services) has its own attributes, as shown in table 2.1 [11].
Presentation, also known as the user interface (UI), focuses on
interacting with the user. Application logic, or business rules, perform
calculations and determine the flow of the application. Business rules are
constraints, usually self-imposed, that companies or organization use to help
them operate in their particular business environments-essentially, they
encompass those practices and policies that define an organization's behavior.
Business rules often define a baseline for application requirements and

15

provide guidance to the developer. In practical terms, these business rules are
goals that developers strive to meet for their applications.
Data services manage information by storing data and providing datarelated functionality. For example, a MySQL running on a Linux Server
computer would be a data service [11].

Table 2.1 Service Attributes of each Application Element

Service

Service Attribute

Type
Presentation

Presentation

of

information

navigation,

and

protection

and
of

functionality,
user

interface

consistency and integrity.

Application

Shared business policies, generation of business

Logic

information from data, and protection of business

integrity.

Data

Definition of data, storage and retrieval of persistent

Services

data, and protection of data integrity.

2.2 Types of Applications

According to the combining or separation of the application elements in
logical layers, the applications could be classified according to the following
types:

2.2.1 Single-tier Applications

In a single-tier application, only one layer supports the presentation,
application logic, and data services. Only one application or application

16

element processes all three of these services. The data itself can be physically
stored in any location, such as on a server. However, the functionality for
accessing the data is part of the application [11].

2.2.2 Two-tier Applications

Two-tier, or standard client/server applications, group presentation and
application logic components on the client machine and access a shared data
source using a network connection. In a two-tier application, the user
interface and business rules are a single layer that runs on the client computer.
Separate applications, such as MySQL or Oracle database servers, provide the
data services. Client/server applications are often two-tier applications, such
as in a Java application that calls a MySQL stored procedure to provide data
to the application. The Java application is one layer, and the MySQL data
services are another layer [11].
Classical two-tier architectures have brought efficiencies to businesses, but
there are also a number of limitations:
Monolithic client applications
Two-tier applications tend to have monolithic client-side components,
which prevent incremental improvements (upgrades and bug fixes) to
the application.
Difficult to scale
Application scaling is poor because of the limited number of database
connections available to clients. Connection requests beyond this limit
are simply rejected.
Difficult to maintain

17

It is hard to maintain client-side application logic because it has to be

deployed to every client. Any change in the logic must be redistributed
to all clients.
Compromised confidentiality
Application logic on the client potentially exposes business rules to
users.
Difficult to use broadly
It is difficult to use two-tier application logic broadly, because
applications are bound to specific database systems and table formats.
Tightly bound to data source
The client is often configured for a particular database, so moving data
to a different database is more difficult.
Poor network performance
A network runs inefficiently because of the amount of raw data that is
transferred across it. Much of the database processing is not localized.

2.2.3 Multi-tier Applications

Tiers are a logical concept. The three tiers are generally described as user
(first), business (second or middle), and data (third); however, there can be
more than three tiers in a multi-tier application. Because of this fact, multi-tier
applications are sometimes referred to as n-tier applications where n is any
number greater than or equal to three.
A service is a unit of application logic that implements operations,
functions, or transformations that are applied to objects. For example, a
business service could be implemented with PHP class that ensures a
purchase does not exceed the buyer's credit limit. In multi-tier architectures,
presentation, application logic, and data elements are conceptually separated.

18

These tiers don't necessarily correspond to physical locations on the network.

For example, all three tiers may exist on only two machines or they may be
deployed on five [11].
Presentation components manage user interaction and request
application services by calling middle-tier components. Application
components perform business logic and make requests to databases [11].
With multi-tier applications, the client provides only one layer: the user
interface. The business rules are performed on a system between the user
interface and the data storage system. This allows the presentation services,
user interface, business rules, and database to reside separately, as illustrated
in Figure 2.1 [11].

Figure 2.1 User Interface, Business Rules, and Database Reside Separately

2.3 Elements of a Distributed Application

Applications could be viewed as being separated into presentation, business
rules, and data services, each application could be built as a set of features or
services that are used to fill consumer requests. When an application is
modeled as a collection of discrete services, the application's features and
functionality

could

be

packaged

for

19

reuse-shared

among

multiple

applications, and distributed across network boundaries, as illustrated in

Figure 2.2.

Figure 2.2 Typical Distributed Web Application

Three-tier architectures are often called server-centric, because they uniquely

enable application components to run on middle-tier servers, independent of
both

the

presentation

interface

and

database

implementation.

The

independence of application logic from presentation and data offers many

benefits:
Centralized components
Components could be centralized for easy development, maintenance,
and deployment.

20

 Load balancing
Application components could be spread across multiple servers,
allowing for better scalability.
More efficient data access
Database connection limitation problem is minimized since the
database now sees only the application component, not all of its clients.
Also, database connections and drivers are not required on the client.
Database connections in two-tier applications are acquired early and
held; in three-tier applications, they are acquired late and released.
Improved security
Developer can secure middle-tier application components centrally by
using a common infrastructure. Developer can grant or deny access on
a component-by-component basis, simplifying administration.
Simplified access to external resources
Multi-tier application simplifies access to external resources, such as
mainframe applications and other databases [11].

2.3.1 Presentation Tier

Presentation tier of a distributed Web application is usually implemented

using Hypertext Markup Language (HTML) because it is standard language
of all Web browsers [11].
HTML is a text-based markup language. It is a simple language for
formatting documents that are displayed in a Web browser. The primary task
of the browser is to render documents according to the HTML tags they
contain and display them on the monitor [12].
HTML pages provide interaction with user in two ways; allowing the
user to jump from page to page through hyperlinks. The other way allows the

21

user to send data to the Web server using the HTML Forms. The Web
browser does not know how the server processes these data. It only sends the
data using HTTP request and gets a response back from the server. The
browser renders the response as a normal HTML document. It does not care
how the server had generated it [11][12].
From the Web browser perspective of view, it only sends HTTP request
for the Web server. The request could be a name of an HTML document or a
name of a server side application with some data sent by the user using
HTML Forms. The Web browser then expects a HTTP response. The
response should be a HTML page which is rendered by the browser [11].

2.3.2 Middle Tier

In distributed Web applications, the middle tier is responsible for:

1. Receiving the requests from the user presentation layer.
2. According to the request and application logic, the middle tier performs
specific tasks, for example read/update a database, send an e-mail or
consume a Web service.
3. Format the response in a human readable fashion using HTML and
send it back to the user.
In this sense, it should be noted that the middle tier in fact generates the
presentation layer [11][13].
There are many languages and platforms could be used to implement the
middle tier. One of the most obvious choices is the PHP.
PHP is an open-source, server-side, Web-scripting language that is
compatible with all the major Web servers (most notably Apache). PHP
makes it possible to embed code fragments in normal HTML pagescode
that is interpreted as the pages are served up to users. PHP also serves as a

22

glue language, making it easy to connect your Web pages to server-side

databases [13][14].
PHP is the Web development language written by and for Web developers.
PHP stands for PHP: Hypertext Preprocessor. The product was originally
named Personal Home Page Tools, and many people still think thats what the
acronym stands for. But as it expanded in scope, a new and more appropriate
name was selected by community vote [13].
When a PHP script executes, it doesn't interact directly with the browser;
only the final product of the PHP script, which usually is an HTML
document, is dealt with by the requesting browser. If a browser were sent an
unprocessed PHP script, the browser would attempt to render the PHP script
as regular HTML. Browsers cannot execute PHP scripts [14].
When a PHP page is requested, before the document is sent to the client,
the document is processed by PHP engine, and the PHP engine executes any
PHP code found in the document. Figure 2.4 illustrates a client request for a
PHP script. The PHP script in this illustration returns a processed HTML
document [14].

23

Figure 2.3 PHP Script Request

2.3.3 Data Tier

This layer refers to the components that manage an applications internal data.
These data are typically under the direct control of a relational database
management system (RDBMS) like MySQL or Oracle. The following section
introduces the database concepts in more details [11].

24

2.4 Introduction to Database Systems

Nearly all business applications need to store large volumes of data, organized
in a format that simplifies retrieval. This is accomplished with a DataBase
Management System (DBMS), a mechanism to manipulating tabular data
with high-level commands. The database management system hides low-level
details, such as how data are stored in a database, and frees the programmer to
concentrate on managing information, rather than on specifics of
manipulating files or maintaining links among them [14].
The most popular data storage model is the relational database, which
grew from the seminal paper "A Relational Model of Data for Large Shared
Data Banks," written by Dr. E. F. Codd in 1970. Although there are different
ways to organize data in a database, relational databases are one of the most
effective. Relational database systems are an application of mathematical set
theory to the problem of effectively organizing data [11].
The standard language used for handling relational database is
Structured Query Language (SQL). The history of SQL begins in an IBM
laboratory in San Jose, California, where SQL was developed in the late
1970s. It was originally developed for IBM's DB2 product (a relational
database management system (RDBMS) that can still be bought today for
various platforms and environments). In fact, SQL makes an RDBMS
possible. SQL is a nonprocedural language, in contrast to the procedural or
third-generation languages such as COBOL and C that had been created up to
that time [14].
Two standards organizations, the American National Standards
Institute (ANSI) and the International Standards Organization (ISO), currently
promote SQL standards to industry. Along this project, MySQL is used as
RDBMS [14].

25

2.4.1 Introduction to MySQL

MySQL (pronounced My Ess Q El) is a multithreaded, multi-user, SQL

RDBMS with an estimated six million installations, which make it the most
popular Open Source RDBMS. MySQL is available as open source software /
free software under the GNU General Public License (GPL), it is possible to
buy commercial licensing arrangements for cases where the intended use is
incompatible with use of the GPL [15].
Over the past ten years, MySQL has truly developed into a world class
product. MySQL now competes with even the most feature-rich commercial
database applications such as Oracle and Informix. Many large companies are
using MySQL already, most notably Yahoo [16].
There are APIs available that allow applications written in numerous
programming languages to access MySQL databases, including: C, C++, C#,
Eiffel, Smalltalk, Java (with a native Java driver implementation), Lisp, Perl,
PHP, Python, Ruby, REALbasic and Tcl; each of these uses a specific API.
An ODBC interface called MyODBC allows additional programming
languages that support the ODBC interface to communicate with a MySQL
database. MySQL is mostly implemented in ANSI C, and, that being a
common "lingua franca" for system libraries, tends to use that as its "native"
language [14].
MySQL works on many different platforms; including AIX, BSDi,
FreeBSD, HP-UX, Linux, Mac OS X, NetBSD, Novell NetWare, OpenBSD,
OS/2 Warp, QNX, SGI IRIX, Solaris, SunOS, SCO OpenServer, SCO
UnixWare, Tru64, Windows 95, Windows 98, Windows NT, Windows 2000,
Windows XP and more recent versions of Windows [15].

26

2.4.2 Database Concepts

In its basic sense a database is simply a grouping of related information

organized for easy processing and retrieval. The actual data in a database is
stored in tables. A table represents some class of objects that are important to
the users. For example, a SCADA system may have a database with table for
RTUs, another table for operators, and another for logged readings. As in
Figure 2.3, each table is built of columns and rows. Each column represents
some attribute of the object represented by the table. For example, an operator
table would typically have columns for attributes such as first name, last
name, employee ID, and privileges. Each row represents an instance of the
object represented by the table. For example, each row in the RTU table
represents a real world RTU [14].
When organizing data into tables, many different ways could be used to
define tables. Relational database theory defines a process called
normalization, which ensures that the set of defined tables will organize the
data effectively [14].

Figure 2.4 Pictorial Representation of a Table in a Database

The relational database is so-called so because they are based on the

relations among the tables. The foundation of the relational database is to
break the data into multiple tables that are related by common information
(keys) [14].

27

In relational database system, each row has a unique identifier that is

used to indicate the row and to relate it to other rows in other tables. Often, a
close inspection of a database will reveal an existing characteristic that make
each row unique; frequently, this can become the primary key. This type of
primary key is called composite. For example, in an Operators table, an
operators Social Security number is a composite primary key. When there is
no column that can be used as a composite primary key, the RDBMS can
automatically generate a unique numeric (incremental) key for each row [14].
A column in a table that stores a value and relates that value to another
table is called a foreign key. For example, a column in a RTU table that stores
the Social Security number of the operator who has the administration
privileges administrate on that RTU is a foreign key [14].

2.5 Security Aspects of Web-Based SCADA System

SCADA systems that monitor and control critical infrastructure such as power
generation and transmission, water and waste water and pipelines over a wide
area network, should be highly secured and out of the access of any
unauthorized party [3].
Hypothetically, by hacking into a SCADA network monitoring water
gates in a dam and taking control of the SCADA system, a malicious hacker
could make disasters by opening and closing of the gates at will.
Putting the SCADA system on the Web get things more risky, but it
also gives the solution as well. By using the available IT security solutions,
which is widely deployed, widely tested and considered to be proven
solutions, the entire problem of the security is almost disappear [3].

28

Security is about controlling access to a variety of resources, such as

application components, data, and hardware. There are three concepts upon
which most security measures are based:
Data Protection
Authentication
Authorization [17]

2.5.1 Data Protection

Data protection is the process of providing data confidentiality, integrity, and

non-repudiability. Data requires protection not only while in transit but also
while it is stored. Regardless of what the data's form, once data enters
unsecured communication channels it becomes vulnerable to attack [17].
Encrypting the data provides data confidentiality. Data encryption uses
a crypto algorithm in conjunction with a crypto key to render data useless to
someone lacking both the correct algorithm and key to decrypt the data. The
crypto key is an additional variable used in the algorithm. A crypto key
contains a numeric value that is limited by the number of bits the key
contains. Although a 40-bit key contains 240, or 1,099,511,627,776, possible
key values, a typical PC could try an exhaustive search of every possible key
value in approximately one week. However, if the crypto key consists of 128
bits, a brute force attack would need to try up to 2128, or 3.4 x 1038, values.
Each additional bit doubles the possible number of values. Crypto keys enable
a public algorithm to be used by multiple parties without compromising data
encrypted with the algorithm [17].
Since the crypto key determines the strength of the encryption, all
encryption algorithms are vulnerable to brute force attacks. A brute force
attack is the systematic attempt to decrypt data using every possible key. For

29

example, if the crypto key used to encrypt a data consisted of only four bits, a
brute force attack would only need to try up to sixteen crypto key values to
compromise the data [17].
Data integrity is achieved through the use of hash algorithms, digital
signatures, and message authentication codes [17].
To ensure the integrity of data, a hash of that data can be sent to
accompany it. The receiver can then compare a hash that it computes on the
received data with the hash that accompanied the received data. If the two
match, the received data must be the same as the data from which the received
hash was created. A hash is a fixed-length string of numbers and characters. It
is computed using a hashing algorithm, such as Message Digest 5 (MD5) or
Secure Hash Algorithm (SHA-1). Hashing is a one-way operation that cannot
be reversed to recreate the original data [17].
A digital signature takes hashing a step further by encrypting the
computed hash using a private key. This extra step can prevent an attacker
from intercepting data and its accompanying hash, modifying the data, and
then simply re-computing the new hash for the modified data. Since a digital
signature is an encrypted hash, an attacker would need access to the original
private key that was used to create the original digital signature. On the
receiving end, digital signatures can be verified using the associated public
key. Digital signatures can be used to enforce non-repudiation, which can
later be used to prove the origin, contents, and timestamp of the data [17].
Message authentication codes (MACs) are used by technologies such as
Secured Socket Layer (SSL) to verify that data has not been altered while in
transit. However, since MACs use a common key for encryption and
verification, they cannot be used to enforce non-repudiation [17].
SSL Provides encryption services to several applications by using
public and private keys to encrypt data transmitted between a server and a

30

client. This method of encryption is one of the strongest encryption

techniques. It uses two keys, one key is public to all users, and the other is
private to the server. If a message is encrypted using the public key, there is
no way to decrypt that message without the private key [17].
While most commonly associated with Web browsers, SSL is also used
to provide encryption services to many other applications [17].
SSL requires the server hosting the application that uses SSL to acquire
a private/public key pair for encrypting the data. Figure 2.5 shows the
encryption process for Web applications [17].

Figure 2.5 Encryption for Webbased transactions

The secure communication process is explained in the following steps:

1. The Web client attempts to connect to the Web server by using SSL.
No additional software is required for the client. The client simply
changes the protocol in the Universal Resource Locator (URL) from
http: to https:.

31

2. The Web server returns the Web server's certificate and public key to
the Web client. The Web client requires the public key to encrypt any
transmissions sent to the Web server.
3. The Web client and Web server enter into a negotiation to determine
encryption levels. The Web server and Web client negotiate to
determine if 40-bit, 56-bit, or 128-bit encryption will be used for the
session key.
4. The Web client generates a session key and encrypts the session key
with the Web server's public key. The session key is set to be the length
negotiated between the Web client and the Web server. Once the
session key is encrypted, the encrypted session key is transmitted to the
Web server.
5. The Web server decrypts the session key using the Web server's private
key. Only the Web server has access to this private key, ensuring that
the connection attempt isn't intercepted by an attacker.
6. The session key is used to encrypt all further data exchanged between
the Web client and the Web server.
The benefit of using application-level security is that the encryption
requires no additional work by the user. The only noticeable change is that the
user must use https: in the URL rather than http: [17].

2.5.2 Authentication

Authentication is the process of identity confirmation, which is the one layer

of security control. Before an application can authorize access to a resource, it
must confirm the identity of the requestor. The requestor establishes an
identity by providing some form of credentials, which is known only to the
requestor and the authenticating host. In some circumstances, the requestor

32

may want to verify the identity of the authenticating host, which is called
mutual authentication [17].

2.5.3 Authorization

Authorization is the process of verifying that an authenticated party has the

permission to access a particular resource, which is the layer of security
control following authentication. Just because an authenticating host has
confirmed the identity of the requestor, it does not necessarily follow that the
authenticated requestor has the correct permissions to access a particular
resource. For example, a normal user can not modifies the settings of a RTU,
but only the administrator can [17].

33

CHAPTER THREE

Case Study One: Water Level Control

3.1 Introduction

This chapter presents a chosen case study. The case study is about
implementing a Web-based SCADA system for monitoring and controlling
the level of water in a network of dams. The system was named Water Level
Control or WLC for short.
The system provides the ability to monitor and control dams distributed on
a large geographical area. The first problem arises, is how to interconnect
such a system. The WLC could work on a wide variety of networks. There are
two requirements in the network to be satisfied:
1. The RTUs and the operator terminals should be able to route IP pockets
to the MTU and the inverse is not necessary. The system needs only
one routable (public) IP address. Other components (i.e. the RTUs and
the operator terminals) could be located behind Network Address
Translation (NAT). This would reduce the cost of the interconnection
of the system dramatically. It also provides a great flexibility in
choosing Internet Service Provider (ISP).
2. The network should support the HTTP protocol, which is a universal
protocol supported by all the ISPs. It is also supported by most of the
intranets.
It is obvious that the Internet could be a good choice, especially for
countries with no infrastructures. For example, when the MTU is connected
to the global Internet, dams and the operator terminals could be located in any
place as far as it can access the Internet.

34

The operator could log to the system to monitor the level of water in any
RTU. The authorized operator could also change the setting of any dam. The
settings include the frequency of data logging (i.e. the number of times the
RTU sends the level of the water to the MTU per hour or day) and the desired
levels of water to be kept by the RTU automation program.
This chapter presents the big picture of how the overall system works.
Then, the implementation of the MTU and the RTU is illustrated.

3.2 The Operation of the Overall System

When the RTU start working, it reads the water level from the sensor, and
sends the reading to the MTU with the RTUs ID and a secret key. The RTU
sends them as an HTTPS request. HTTPS is used to guarantee the security of
the connection.
When the MTU receive the request, it checks the RTU ID and the
secret key (a value known only by the RTU and the MTU used to authenticate
the RTU) with its database. If no match found, the MTU would return an error
code and ignore the request, otherwise if the RTUs ID and the secret key is
matched with the database, the MTU will add a record to the readings table
conforming that the RTU had sent the received reading in the current time and
date. Also, the MTU will send new configuration settings back to the RTU as
the HTTPS response. The configurations will contain the new desired levels
of water in that dam and the frequency of logging the readings from the RTU.
When the RTU gets the response back, the RTU updates its
configurations. Then, the RTU decides to open or close the dam gate
according the new downloaded desired levels and the water level got from the
sensor.

35

The RTU will wait for some time (according to the logging frequency)
and start the cycle again.

3.3 Master Terminal Unit

MTU provides two services:

1. RTU Service Provider: This service handles the communications
between the MTU and the RTUs.
2. HMI Provider: This service handles the operators requests to allow
them to administrate the system.
Both of the above service providers are implemented in PHP to provide an
interface to one back-end database. The RTUs and the operators do not have
the ability to access the database directly, because of the security risk coming
from such topology. Figure 3.1 shows a block diagram of the system MTU.

36

Figure 3.1 MTU Block Diagram

3.3.1 The System Database

The database is a very important part of the system. It provides data-related

services. It is responsible for:
1. Storing information about the terminals IDs and their secret keys.
2. Storing the information about the desired level of water in each dam for
each month of year.
3. Saving the history of readings for each RTU.
4. Storing information about the authorized users and their passwords.
In other words, the database stores all the data needed by the MTU to
perform its tasks. MySQL 4.2 was used in this thesis as a RDBMS. It had
been tested on Fedora Core 3 Linux in a Pentium 4 based server.

37

A block diagram of the database developed for WLC system is showed in

Figure 3.2.

Figure 3.2 Database Model

As shown in Figure 3.2, the database is consisted to have four main

tables:
users table: This table stores users names, passwords and their
privileges. The table is used by the HMI to authenticate (using the user
name and password) and authorize (using usertype) users. Each user
should have one row in this table.
wlc_terminals table: The table stores information about the terminals.
The information include: terminal name or ID, secret key (which are
used to authenticate terminal by the MTU), the location of the terminal
relative to the length of the river, longitude, latitude to show the
geographical location of the terminal, a simple description of the

38

terminal and the period of time the terminal should wait between each
logging of data from the terminal to the MTU. Each terminal should
have one row in this table.
wlc_des_levels table: The table stores the planned or desired level of
water for each dam in each month of year. The values are set by
authorized system operator throw the HMI. The RTU will receive those
values from the MTU using the HTTP/HTTPS.
wlc_readings table: The table stores a historical values of the level of
water for each dam. This achieved by storing the terminal ID which had
logged the level, the level itself and the date and time which the level is
logged in. The RTU will log these levels to MTU using the
HTTP/HTTPS. The HMI will use this table to build its report and to
monitor the dams activities.

3.3.2 The RTU Service Provider

The RTU Service Provider (RSP) is implemented using PHP. It is

implemented as a single PHP page. The page (logger.php) will get three
parameters: RTU ID, secret key and the water level as an HTTPS request.
The RSP checks the RTUs table (wlc_terminals) for a RTU with
matched ID and secret key. If the table does not contain such RTU, the RSP
returns error code (RTU ID /secret key are invalid) and the request will be
ignored.
Otherwise, if the ID and secret key matched successfully with the table,
the RSP will add a record in the readings table (wlc_readings). The record
will be consisted of: RTU ID, date and time of receiving the request (same as
the date and time of taking the reading itself) and the level of water sent by
the RTU.

39

After that, the RSP returns back a response to the RTU. The response is
formatted using eXtensible Markup Language (XML). XML is standard for
data exchange in the Internet applications. XML allows user defined tags that
make XML document handling flexible.
The response contains two main parts; the first one is a conformation code
to tell the RTU that the logging was done successfully. The second part is the
new settings for the RTU. These settings are extracted from the database. The
settings are consisted of:
1. How may times the RTU should log the level of water to the MTU.
2. The desired minimum and maximum level of water for each month of
year.
Figure 3.3 shows the flowchart of the RSP subsystem.

40

Figure 3.3 RSP Operation Flowchart

Other aspect of the RSP is to provide alerting system for the users. The
MTU could be configured to send emails and SMSs to the persons in charge
when the level of water on one or more of the dams is out of the desired
range.

41

3.3.3 HMI Provider

The HMI provides a Web-based GUI to the users to monitor and configure
the system. Operators use Web browsers to access the HMI of the system.
The HMI Provider generates HTML code that is rendered in the operator
terminals.
The HMI Provider enforces the authentication and the authorization in
the system. It will not let any unauthorized person to access a restricted area
in the system. This is done by using single point of entry. Users are not
allowed to access Web pages directly, instead, they have to access the main
page index.php and pass it the request they want to be done. The main page
performs security checks, and if every think is okay, it transfers the control to
the wanted page.
Authentication is done by asking the user to send his credentials (user
name and password), and compare them with the users name and passwords
stored in the users table. If there is such a pair, the user is considered
authenticated and will be given a user type by the system. The user type is
determined using the usertype field in the users table. Figure 3.4 shows a
flowchart of the authentication and authorization in the system.

42

Figure 3.4 System Authentication and Authorization

WLC have three types of users: Administrator, Operator and

Anonymous. All users who did not provide a user name and password are
considered to be Anonymous users. By default they can only monitor the
system. Administrators can block them from doing that. Operators can
monitor dams and change their settings. Administrators can do that, in
addition they can manage users too.
The HMI allows authorized users to make the following tasks:
1. Manage RTUs
Authorized user can use the HMI to add and delete RTUs, also can edit
the settings of RTUs. This operation requires accessing two tables;
wlc_terminals and wlc_des_levels. Figure 3.5 shows a flowchart of how
HMI Providers manage RTUs.

43

Figure 3.5 Managing RTU in HMI Providers

2. Manage Users
System administrators can add and delete users. They can also limit the
privileges of the users. This operation requires accessing the users
table. Figure 3.6 shows how HMI Provider manages users.

44

Figure 3.6 Managing Users in HMI Provider

3. Monitoring and Reporting

Authorized users can use the HMI to monitor the level of water in
dams. They can also build printable reports of the history of the water
levels in each dam. There are four types of reports supported by the
system:
Current level Report: Shows a list of each RTU with the last
level logged from it.

45

 Disconnected RTUs: Shows a list of the RTUs which had never

been connected to the MTU since a specific duration and the last
time they had connected to the server.
Bad level RTUs: Shows a list of the RTUs in which the level of
water is not within the desired range. It also shows the level of
water in those RTUs.
History Report: Shows all the levels logged from a specific dam,
the date and time of logging.

3.3.4 MTU System Requirements

The MTU is implemented using PHP and MySQL. Both of them are
supported by many platforms and operating systems. The list of supported
operating systems includes: Linux, Windows, AIX, FreeBSD, MacOS and
Solaris.
Moreover, they could be run on Intel or AMD made processors both for
32-bit and 64-bit. Sun Sparc and Alpha based servers are supported too.
The MTU is tested successfully on:
Operating System : Linux and Windows 2003 Advanced Server.
CPU

: Intel Pentium 4 (2.8 GHz).

RAM

: 512 MB.

Hard Disk Usage : 7 GB for Windows.

of the Overall

5 GB for Linux.

System

46

3.4 The Remote Terminal Unit

The following subsections describe the hardware and software architecture of

the implemented RTU of the WLC. Physically, RTU is consisted of two parts:
a personal or industrial computer and a field data interface device.
The computer runs programs which are responsible for controlling the
field data interface device and for communicating with the MTU. On the
other hand, the field data interface device is designed to read the level of
water and to apply the decision of the computer to open or close the gate of
the dam.

3.4.1 Field Data Interface Device

The field data interface device carries two functions; sensing the level of
water and controlling the operation of the opening and closing the gate of
dam. The device is interfaced to the RTU computer using the parallel port to
guarantee the compatibility of the device with a wide range of commercially
available computers on the market. The following subsections describe how
the device works.

3.4.2 Parallel Port Interface

Parallel port is one of the most widely used ports for embedded projects. This
port allows the input of up to 9 bits or the output of 12 bits at any given time,
thus requires minimal external circuitry to implement many tasks. The port is
composed of 4 control lines, 5 status lines and 8 data lines. Parallel pot is
found on most of personal and industrial computers as a standard part.

47

Single computer may have more than one parallel port. Each port is
assigned a base IO address to be accessed from.
Parallel port works in many modes. The simplest mode (compatibility
mode) is used in the thesis. In this mode, Parallel port lines are grouped by
three different groups:
Data group: It is used to send data from computers to external devices.
It has eight latched output lines and the group is associated with an 8bit CPU port. The address of this group is: base address of the port.
Control group: It is used to control the operation of external devices.
It contains four latched output lines. The address of this group is: base
address+2.
Status group: This group is used by the computer to obtain the status
of the external devices. It contains five lines (-ERROR, SLCT, PE, ACK and BUSY), which are directed from the external device to the
computer. It is fed into a CPU port, the address of which is: base
address +1 [18].

3.4.3 Water Level Sensor

The water level sensor device detects immersion of the bare ends of the
sounding wires by taking advantage of the fact that water conducts electricity
better than air. The sensor provides eight level detectors. By sensing
immersion of each end of these detectors, the sensor determines the level of
water. The output of the sensor consists of four digital signals. They represent
the higher probe number immersed by water. Then, by using a look-up table
(set by RTUs operator), the RTU software determines the real value of the
water level in meters referenced to the Mean Sea Level (MSL). Table 4.1
shows a sample look-up table.

48

Table 4.1 Sample Look-up Table

Probe No. MSL (meter)

8

40.5

37.5

34.5

31.5

27.5

24.5

21.5

17.5

The detectors should be installed in ascending order. Which mean

probe one should be located at the lower level to be measured; probe two
above and probe seven should be the higher one. Figure 3.7 shows the
alignment of probes.
When the bare ends of a wire both touch the water, current begins to
flow; however, insufficient current flows to be read by the RTU. A digital
buffer is used to both voltage conditioner and to provide protect the inner
stages from being damaged by the outsides effects.
As shown in Figure 3.8, the level sensor circuit is consisted of four
stages.

49

Figure 3.7 The Alignment of the Water Level Sensor Probes

Figure 3.8 Water Level Sensor Stages

Stage one contains the electrodes or probes which are simply bare ends
of sounding wires. When both ends immersed by water; current will
begin to flow. This is used by the second stage to detect the immersion.
Stage two is digital buffer which serves as a voltage threshold detector
and also it protect the other stages from the outside conditions such us

50

static discharge. The 74244 IC was used for this purpose. It provides
octal buffer/line driver with Schmitt trigger actions. Schmitt trigger
logic reduces the problem of a noisy input by using two voltage
thresholds: a high threshold (1.5 volt) to switch the circuit during lowto-high transitions and a lower threshold (0.9 volt) to switch the circuit
during high-to-low transitions. Such a trigger scheme is immune to
noise as long as the peak-to-peak amplitude of the noise is less than the
difference between the threshold voltages. A gate with the Schmitt
trigger feature has a small hysteresis curve drawn inside the gate
symbol. Schmitt triggers are mostly used in inverters or simple gates to
condition slow or noisy signals before passing them to more critical
parts of the logic circuit.
Stage three determines the higher probe immersed by water. The input
to this stage is eight digital signals come from the digital buffer. Each
signal indicates whether the corresponding probe is immersed by water
or not. If the signal is logic one, then it indicates the immersion of the
detector. Logic zero indicates the detector is not immersed. The output
of this stage is the higher number of immersed probes. For example if
probes number one to probe number five is all immersed; the output
would be digital five (0110)2. This is done using a priority encoder. A
priority encoder determines the index of the most significant 1 in the
data input. This value is then placed in the output. A 74148 IC is used
to implement this function. Table 4.2 shows the truth table of the 74148
(8 to 3 priority encoder).

51

Table 4.2 Truth Table of the Third Stage

Input

Output

IN8

IN7

IN6

IN5

IN4

IN3

IN2

IN1

GS

A2

A1

A0

Stage four contains a buffer used before the direct connection to the
Parallel Port of the RTU computer, in order to protect the port from any
damage caused by failure in the device.
Figure 3.3 shows the circuit diagram of the water level sensor. The four
signals are interfaced to be read from the parallel port using the status
group.

3.4.4 Dam Gate Actuator

RTU opens or closes the gate of the dam by sending a digital signal to dam
gate actuator. Sending logic 1 on the signal (OPEN) cause the opening of dam
gate. On the other hand, sending logic 1 on the signal (CLOSE) causes the
closing of dam gate as shown in Figure 3.9. To be able of driving the actuator
with a relatively larger current, a signal driver (ULN2803) is used.

52

Figure 3.9 Detailed Schematic Diagram of the Field Data Interface Devices

53

3.4.5 Programming the RTU

The software part of the RTU is consisted of two programs: Local

Administration Interface (LAI) and the automation program. Both of these
programs are implemented mainly in Perl. The following sections introduce
Perl and describe each program.

3.4.6 Perl

Perl is short for Practical Extraction and Report Language. Perl is an

interpreted language whose compiler, tools, and libraries are all available as
open source under the terms of the Perl Artistic License and the GNU GPL
from

the

Comprehensive

Perl

Archive

Network

(CPAN)

at

http://www.cpan.org/. Perl was introduced by Larry Wall in 1987, and since

become a world of its own [19].
Perl is designed to assist the programmer with common tasks that are
probably too heavy or too portability-sensitive for the shell, and yet too weird
or short-lived or complicated to code in C or some other glue language. Perl
grew to become a widely used language in many fields of applications [20].

3.4.7 Local Administration Interface

LAI program allows RTU operator to configure and maintain the RTU. The
application provides a GUI to edit the RTU configuration file.
The program is implemented as a plug-in to the Webmin. Webmin is an
open source, Web-based interface for system administration for Unix/Linux
host. Using any browser that supports tables and forms (and Java for the File

54

Manager module); it is possible to get all the administration tasks done to the
computer, for example adding user, formatting disk, installing programs, etc.
Webmin consists of a simple Web server, and a number of modules
which directly update system configuration files. The web server and all
modules are written in Perl version 5, and use no non-standard Perl libraries
[21].
Webmin provides extendable infrastructure allowing developers to
extend its functionality. Developers are able to develop plug-ins modules.
These modules, usually, provide a Web-based user interface to administrate
software running on the system.
Webmin provides the security roles and API framework that greatly
simplify the development of such programs [21].

3.4.8 RTU Automation Software

The RTU Automation Software (RAS) is where the real work is done. LAI
only provides a method of configuration of the RTU. The RTU automation
software performs the following tasks:
1. Reads the water level from the sensor.
2. Sends the level value to the MTU, and update the configuration file
back from the MTU.
3. Decides the appropriate action to do with dam gate, according the new
settings and the obtained water level.
The RTU automation program is implemented mainly in Perl. The
hardware is accessed using programs written in C language.

1. Configuration Files
RAS needs two configuration files:

55

 settings-lcl.config: This file contains RTU ID, secret key, RSP URL,
parallel port base address and the look up table to map detector number
to level MSL in meter. RTU operator could modify these values using
the LAI only.
settings-mtu.config: This file contains the desired level (minimum and
maximum) and the logging frequency. These values could be modified
using LAI or by the MTU.

2. Accessing the Hardware

To read from the sensor and to control the gate of the dam, RAS needs to read
and write from and to Input/Output (I/O) addresses directly. This is achieved
by developing two programs using C language.

The first program is out. The usage syntax:

outb value port_add

The function of this program is to write the value to the port address
port_add.

The second program is inb. The usage syntax:

inb port_add

The program reads the input value from the port address port_add, and prints
this value to the standard IO device. Both of the programs are simple

56

wrappers to the inb and the outb functions existed in the <sys/io.h> header
file [22].
The interfacing between those programs and the Perl is done using
backquotes(`) feature of the Perl programming language. The backquotes
simply runs the program named inside it, and store its output to the variable
left of it. For example:

$thedate=`date`;

This runs the date command of the operating system and instead of displaying
the date in the screen, the date is stored in the variable $thedate.
The program gets the base address of the parallel port from the
configuration file.
To read the water level sensor, the program read the status group of the
parallel port:

$stts_add=$base_add+1;

#status group address

$stts=`in $stts_add`;

#read byte from status port

$stts &=120;

#mask the 3 LSBs

$stts /=8;

#shift 3 bits to the right

#$stts is the status port value

To open the gate of the dam, the program should send (00000001)2 to the data
port:

57

`out 1 $base_add`

To close the gate, the program should send (00000010)2 to the data port:

`out 2 $base_add`

3. Communicating with the MTU

The communication with the MTU is done using the HTTP or HTTPS
protocol. The HTTPS guarantees the security for the system. This is done
using standard Web library of Perl (LWP).
To communicate with the MTU three parameters should be known for the
RTU:
The full URL of the RSP. For example the URL could be: https://mtuaddress/rsp.php.
The RTU ID and the secret key.
The level of water.
The first two parameters are set by the RTU operator using LAI. They are
saved in the configuration file. The third one is got from the field data
interface device. The final request would be something like this:

https://mtu-address/rsp.php?rtu=rtuID&secret=secretKey&level=number

When the RTU sends this request, it gets the response back, and checks
the response. If the response contains error (Invalid RTU or secret key for

58

example); the RTU logs this error to the system log. Otherwise, if every thing
is ok, the RTU will replace the old configuration file with the new one.

4. Deciding to Close or Open the Dam Gate

Schmitt trigger logic is used to decide to open or to close the gate of the dam.
For each month of the year there are two values, maximum and the minimum
level of water desired to keep the real level of water within.
If the measured level is within these values no action is done, which
means the gate is kept as it is whether it was opened or closed. If the
measured level is above the maximum value, the program sends a signal to
the gate to be opened. So that the reserved water would be discharged and
then the level of water would get down. And if the measured level is below
the minimum value, the program sends a signal to the gate to be closed.
Figure 3.10 shows a flow chart of the RTU automation software.

3.4.9 System Requirements for the Software Programs

Since Perl is a scripting language available on the most modern (and even
old) operating systems, the Perl part of the application is portable as it is to all
of these operating systems. The list of the supported operating systems by
Perl includes: Linux, Windows, MacOS, FreeBSD, AIX and Solaris. It would
also run on any processor architecture supported by these operating systems,
including: x86, Alpha, ARM, etc.
The part written in C language is a source portable to all the real
POSIX operating system. The list includes: Linux, FreeBSD, AIX and
Solaris. Moreover, porting it to Windows or MacOS is very easy.

59

Figure 3.10 Flow Chart of the RTU main program

3.5 Operator Related Instructions for WLC

This section describes the steps and instruction that should be followed by the
operator to configure and use the WLC system.

60

3.5.1 MTU Administrator

The access of the MTU is done across the HMI. As the HMI is a browserbased application, the operator has to use a web browser (such as Mozilla
Firefox or Microsoft Internet Explorer) to get things done. For example, the
operator should write (http://hitech-iraq.com/wlc) address in the address bar
of the browser. The browser would then show the main HMI page. From
there, all the functions of the system could be accessed. Figure 3.11 shows the
front page of the system.

Figure 3.11 Front Page of the WLC system

61

1. Logging in
The user should provide a user name and password to be able to access
the administration part of the HMI. Non authenticated users would only
able to monitor the dams, but could never modify anything. The user
name and password (by default admin for both) should be entered in
the specified field in login form, as shown in Figure 3.11.

2. Managing RTUs
Authenticated user who has operator privileges can add, remove and
modify the settings of any RTU. Figure 3.12 shows a screenshot of the
RTU administration main page. The page could be accessed by clicking
the RTU Administration on the main menu.

Figure 3.12 RTU Administration Main Page

To add RTU: From the RTU administration page showed in Figure

3.12, Add New Terminal should be clicked. After that, the

62

operator should fill the form and then click the submit button.
Sample form page is shown in Figure 3.13.

Figure 3.13 Screenshot of the New Terminal Form

To modify the settings of an RTU: From the RTU

administration page showed in Figure 3.12, the operator
should click on the RTU want to edit. A form will then
showed populated with the previous settings. Operator should
modify these settings to the values wanted and then click the
submit button. Figure 3.14 shows a screenshot of the editing
page.

63

Figure 3.14 Editing RTU Form

To remove a RTU from the system: From the RTU

administration page showed in Figure 3.12, the operator
should click on DEL link beside the RTU want to remove.

3. Managing Users
Authenticated user who has administration privileges can add, remove and
modify the settings of any user in the system.
To access user management area, the `Administration` hyperlink in the
main menu in the front page should be clicked, then `User Manger`. Figure
3.15 shows the users managements main page.

64

Figure 3.15 Users Managements

From the above page, one of the following operations could be done:
Adding user: `New` button of the tool bar should be clicked, and
then the operator should fill the appeared list. And click Save, as
in Figure 3.16. The new user should be assigned to one of the listed
groups. Administrator group provide the user with full control of the
system. Operator group provide the user with ability to control the
RTUs and to monitor them.

65

Figure 3.16 New User Form

Removing user: The operator should check the check box to the
left of the users name to be deleted, and then click the `Delete`
button in the tool bar of Figure 3.15.
Modify the information of some user: From the page showed in
Figure 3.15, the operator should click the name of the user in
concern and then modify the information existed in the appearing
form as shown in Figure 3.17.

66

Figure 3.17 Editing User Information

4. Building Reports
The system gives the public Internet users the ability to monitor and
getting reports of the system. The system administrator can restrict the
access to this area to specific groups only. To access the monitoring
and reporting area, user should click the `Monitoring & Reports` button
in the main menu. Figure 3.18 shows the reporting main page.

67

Figure 3.18 Monitoring and Reporting GUI

6.2.2 RTU Administrator

Configuring the RTU means the process of defining the MTU and the
ID/secret key to be used by the automation program. This information is
stored in a configuration file called rtu.config. The process of configuration
could be achieved either by modifying the file manually using any test editor
(such us vi or gedit). Otherwise, the LAI provides a Web-based GUI to do the
same job.

68

3.6 Tested Environments for the WLC

WLC had been tested successfully in a number of different environments.

These environments are described in details in the following sections.

3.6.1 Local Area Network

The first testing environment was implemented on a local area network

(LAN) connected with each other by a central hub/switch, this system was
also used during the development of WLC. Fedora Core 3 was used in this
system for both of the RTU and the MTU.
Two PCs were used, the first one named: mtu.alnahrain.edu.iq, its IP
was manually configured as: 192.168.0.1. The other PC was named:
rtu.alnahrain.edu.iq, and its IP was configured as: 192.168.0.2.
WLC run successfully in this environment. Figure 3.19 shows a
schematic diagram for the LAN testing environment.

69

Figure 3.19 Tested LAN Network

3.6.2 Global Internet

Internet provides an economic communication infrastructure for such a

geographically distributed application. Nowadays, accessing the Internet is
very inexpensive and available even in the rare areas. Moreover, the cost of
having MTU on the Internet could be largely reduced by taking the
commercial hosting approach which could be got for less than 10$ per month.
The factors to choose the type of connection to the Internet for the
MTU are different from those for the RTUs. The MTU should be connected
to the Internet through a very reliable and high speed connection with an IP
address accessible from all the RTUs. Fiber connection is the best solution for
such requirements. The only limitation is that the fiber is available only on big
cities of the industrial countries. The other option is to use a VSAT

70

connection. VSAT services are very expensive and less reliable than the fiber
based ones.
On the other hand, RTUs need a limited bandwidth to achieve its task.
The failure of the connection of the RTU would bring only the corresponding
node down, while the failure of the connection of the MTU would bring the
entire system down. Moreover, RTUs are often located in rare areas where no
fiber connection is deployed. From economical point of view, the system
would usually have a connection for each RTU, which mean a low cost
connection would bring the overall cost of the system down dramatically. For
these reasons the connection of the RTU to the Internet usually selected from
a different category of those for the MTU.
The System has been tested on many connections type for both of the
MTU and the RTUs. The following sections describe those environments.
1. VSAT modems Connection
The system has been tested on two deferent approaches. The first one is
a home hosted server, whereas the other approach is to rent virtual host
in a shared server. The RTU and the Operator workstations connection
to the Internet had been tested on variety of options. In the home hosted
server scenario, the MTU was installed on a local server which is
connected to the Internet using a VSAT modem. The server was fully
configured and maintained locally. Figure 3.20 shows a diagram of the
implemented system. A public (routable) IP was obtained for the
server.

71

Figure 3.20 Accessing using Internet

2. Shared Server
The previous approach is quite expensive as the MTU should be online
all the time and should be provided with a reliable connection to the
Internet. The server should be also maintained by highly skilled
administration staff. The cost of all of these items plus the hardware of
the server could cost more than $1,000 per month. For a smaller budget
projects the shared Web hosts are a better solution. Commercial shared
Web hosts are providing a very suitable space and processing power for
a reasonable monthly fee. Most of these hosts guarantee the availability
and the security of the system to their customers. The system has been
tested

on

shared

host

provided

from

Yahoo,

Inc.

on

http://www.hitech-iraq.com/wlc. The only feature which had been

disabled on this scenario is the SSL. The hosting company had asked

72

for extra $50 to enable the SSL for the site. Figure 3.21 shows the
implemented network.

Figure 3.21 MTU on a Shared Server

3. Accessing using Dialup

Dial-up access is an inexpensive but slow form of Internet access in
which the client uses a modem connected to the computer and a
telephone line to dial the Internet Service Provider's (ISP) node, a dialup server type such as the Point-to-Point Protocol and TCP/IP protocols
to establish a modem-to-modem link, which is then routed to the
Internet. Dial-up requires no additional infrastructure on top of the
telephone network. As telephone points are available throughout the
world, dial-up remains useful for some applications in some areas.
Dial-up is usually the only choice available for most rural or remote
areas where getting a broadband connection is impossible due to low
population and demand. The system had been tested successfully using

73

Uruklink ISP which is the largest dialup ISP in Iraq as shown in Figure
3.22.

Figure 3.22 Network Diagram of the Dialup Access.

4. Accessing using GPRS

General Packet Radio Service (GPRS) is a mobile data service
available to users of Global Services Mobile Communications (GSM)
mobile phones. GPRS has been introduced in mobile phones to allow
users to have access to the Internet easily. Asiacell mobile network was
used to test the system. The system worked without any problem.
Figure 3.23 shows a network diagram for the implemented system.

74

Figure 3.23 GPRS Network

5. Accessing using Satellite based GPRS

ThurayaDSL satellite IP modem offers high-speed GPRS packet data
communication via Thuraya satellite.
ThurayaDSL provides easy to install, user-friendly and a cost
effective solution for high-speed (up to 144 kbps) data communication
anywhere in Thuraya's coverage area of more than 110 countries in
Europe, North and Central Africa, large parts of Southern Africa, the
Middle East, Central and South Asia. The system has been tested
successfully with this network as shown in Figure 3.24.

75

Figure 3.24 ThurayaDSL

3.6.3 VPN Network

A Virtual Private Network (VPN) is an extension of the private network that

encompasses encapsulated, encrypted, and authenticated links across shared
or public networks. A VPN mimics the properties of a dedicated private
network, allowing data to be transferred between two computers across an
internetwork, such as the Internet. Point-to-point connections can be
simulated through the use of tunneling, and LAN connectivity can be
simulated through the use of virtual LANs (VLANs).
VPN was added to the testing environments to enforce a stronger
security to the system. It is used to establish secure connections between the
MTU and the RTUs.
The system was composed of two VSAT systems; one was using public
(routable) IP addresses. This one is used to connect the MTU to the Internet.

76

The other which connects the RTU to the Internet was using virtual IP
(behind NAT) addresses. Each VSAT was obtained from different ISP. Two
VPN routers were configured to fit the appropriate requirements to establish a
VPN connection with the other end.
At each end two or more computers were connected to each other via a
hub/switch to form a network. Figure 3.25 shows an illustrated diagram for
the network.

Figure 3.25 Network Diagram of the Implemented VPN

Although, the test was done using VSAT to connect the RTU to the
Internet, all the other type of connection described in the pervious sections
could use VPN to enforce a better security to the system.

77

CHAPTER FOUR

Case Study Two: VSAT Modems

Monitoring System

4.1 Introduction
This chapter introduces a second case study to show how simple it is to port
the system to serve a completely different application. The new application is
a Very Small Aperture Terminal (VSAT) modems monitoring system (VMS).
Its function is to monitor the network traffic of VSAT modems and
generating reporting charts and tables. The system was implemented
practically and tested successfully in a production environment. The
following sections describe the system briefly.

4.2 System Overall Operation

The system allows VSAT-based ISP companies to track the upload and
download rates of their customers VSAT modems remotely. Also, the system
enables these companies to provide their customers with the ability to login to
the site and monitor their own modems remotely too. This is done by
installing a small program on the modem (RTU). And by providing a central
server (MTU) to which the modems connect.
The system uses the same infrastructure and technologies used in WLC.
The basic sense of the system is to have a program working on the VSAT
modem which periodically measure the upload, download rates and the

78

pinging delay (described later) and send these values to the MTU. Figure 4.1
shows a block diagram of the VMS system.

Figure 4.1 Block diagram of VMS

4.3 Master Terminal Unit

Just like WLC, the MTU of the VMS is implemented using PHP and MySQL.
The MTU provides the service to the RTUs using the RSP subsystem and to
the users and operators using HMI. The MTU was hosted in a shared Web
host.

4.3.1 The System Database

There are three main tables in the database system:
1. The modems table has a row for each VSAT modem installed for the
company. It contains information about that modem (serial number,
title, secret key, upload rate, download rate, the owner of the modem,
geo-location and a short description of it).

79

2. The modem_traffic table records the entire upload/download rates

history. These values are got from the RTU program.
3. The users table stores the names and the passwords of each user of the
system. It stores the type of user too. This table is used to authenticate
the users when they tries to login to the HMI. It is also used by the
modems table to reference the modems owners.
Figure 4.2 shows a model diagram of the database used in the VMS
system.

Figure 4.2 Model Diagram of the Database of the VMS System

4.3.2 RTU Service Provider

As for WLC, the RSP of the VMS is responsible of communicating with the
RTU (here is a program running on the VSAT modem). The RTU sends an
HTTP request to the RSP. The request contains the serial number of the
VSAT modem, the secret key, the upload rate and the download rate and the
pinging delay.
The RSP first checks the serial number and the secret key and match
them on the modems table. If not matched, the RSP will ignore the request
and send error code response. Otherwise, the RSP adds the download and the

80

upload values to the modem_traffic table and mark them with the receiving
time and date. It sends back an acknowledgment code to the RTU to prompt
successfully done. Figure 4.3 shows a flowchart of the RSP of the VMS.

Figure 4.3 MTU-RTU Interaction

The RSP also provides alerting system for end users. The MTU could
be configured to send e-mails and SMSs to the persons in charge if one or
more modems got down or have a high error rates.

81

4.3.3 HMI Provider

HMI of the VMS provides a browser based interface to access the system by
users or operators. HMI provides the following services to the authorized
users:
1. RTU (modems) Management
Authorized user can use the HMI to add or delete RTUs (modems) to
the system; also can edit the settings of RTUs. The settings include an
alias to the modem, secret key, the owner of the modem, the geolocation, and the reserved upload, download and brief description of the
modem. The operation requires accessing the modems table.
2. Users Management
System administrators can add and delete users. They can also limit the
privileges users. This operation requires accessing the users table.
3. Monitoring Modems History
Operators and the modems owners can monitor their modems. The
monitoring page shows chats to visualize the upload and the download
rate along with past 36 hour. The monitoring reports is extracted from
the modem_traffic table.
4. Geographic Information System Integration
Geographic Information System (GIS) is a computer based information
system used to digitally represent and analyze the geographic features
present on the Earth' surface. GIS is used on HMI of the VMS to
provide a visualization of the geographical distribution of the modems
on the map. This had been done on top of a free service provided by
Google to integrate Web mapping on the Web applications. Google

82

provides APIs that allow developers to integrate maps and show their
information over it and integrate all of these in their sites.
Figure 4.4 shows a block diagram of the MTU of the VMS.

Figure 4.4 Block Diagram of the MTU

4.4 Implemented RTU

The RTU in this system run on the VSAT modem itself. The selected VSAT
modem, which is iDirect 3000 series VSAT modem, is Linux based routers.
This means that the modem is a small computer which is powered by Linux.
This computer connects to the satellite using a VSAT modem card, and
connects to the locale network using an Ethernet card. The Linux, in between,
is responsible for the process of routing the incoming and the outgoing
packets between these network interfaces. The use of Linux to power the
modem had largely simplified the process of the development of the RTU
program, since the development tools are available for the Linux for no
charge and also because of the well documentation of these tools.

83

Such type of devices, where the computer is inside the device without a
clear appearance to the end users, is usually called embedded computers.
Usually, the computer is characterized with limited resources (CPU power,
memory and storage size) and other power and size constrains. The system,
usually, required to boot and response fast. Because of the flexibility and
source availability of Linux, it became a major player in the embedded OSes
industry.
The iDirect modem uses an Advanced RISC Machine (ARM) based
processor (IXP420). IXP420 is designed by Intel especially to server as a
network processor. This processor has a completely different instructions set
and architecture from those of the x86 processors used in the standard PCs.
For this reason a cross compilation was required.

4.4.1 Cross Compilation

Cross compilation occurs when a compiler running on one system (host)
produces executables for another system (target). This is an important concept
when the target system doesn't have a native set of compilation tools, or when
the host system is faster or has greater resources. Cross compilation is
accomplished using a cross-compiler toolchain and cross-compiled libraries.
Toolchain is the set of tools used to build applications, or to create an image
for embedded devices [23][24].
The crosstools had been used to build the toolchain for IXP420. The
crosstools is an open source project to build cross compilation tools for a
large number of processors and platforms. The produced toolchain contains
the GNU C Compiler (GCC), which is the most widely used C compiler in
Linux [23].

84

4.4.2 Microperl
Microperl is the absolute bare minimum build of Perl with no outside
dependencies other than ANSI C compiler. Default configuration files are
provided with the bare minimum settings that allow the core Perl interpreter
to build properly. None of the language's core features are missing from this
interpreter. Of course it does not support the features provided by the plug-in
modules, which is come by default with standard Perl, but it is sufficient to
run basic Perl applications. Microperl was compiled using the GCC produced
from the crosstools [23].

4.4.3 Traffic Measurement

The system measures the download and the upload rates, the percentage of
packets errors and delay of pinging a reference server. The upload and
download rates are measured by analyzing a specific file on the /proc file
system.
The /proc file system, in Linux, is a direct reflection of the system kept
in memory and represented in a hierarchal manner. The effort of the /proc file
system is to provide an easy way to view the current or the past status of the
system. For example the file /proc/loadavg provides information about
average of system load for the last 1, 5 and 15 minutes [22].
The file which is used to measure the traffic is the /proc/net/dev. This
file shows a lot of information about each network interface installed on the
computer. The information includes the downloaded and the uploaded bytes
since the booting of the system along with information about the packets with
errors in the up and down streams.

85

The traffic rate for each of these values could be calculated simply by
watching the delta of each value and dividing it by the delta time.

value= (value2-value1)/T

On the other hand, the program measures the ping delay too. Ping is a
diagnostic tool (program) used for verifying connectivity between two hosts
on a network. It sends Internet Control Message Protocol (ICMP) echo
request packets to a remote IP address and watches for ICMP responses and
measure the time between them. The RTU uses the standard ping program
installed with Linux extract the ping delay.

4.4.4 The Implementation

The RTU was implemented purely in microperl. The task of the program is to
measure the upload rate, download rate, error percentage and the ping delay
and send all of these data to the MTU as a HTTP request. The program will
send the modem serial number and the secret key, which are stored in a
configuration file, to authenticate the modem to the MTU. Figure 4.5 shows a
flowchart of the program.

86

Figure 4.5 Flowchart of the RTU subsystem

4.5 Operator Related Instructions for VMS

This section describes the steps and instruction should be followed by the
operator or users to configure and use the VMS.

87

4.5.1 MTU Administrator

The access of the MTU is done across the HMI. Just like WLC, HMI of the
VMS is a browser-based application, the operator has to use a web browser
(such as Mozilla Firefox or Internet Explorer) to get things done. The address
of the MTU is http://hitech-iraq.com/beta. The browser would then show the
main HMI page as shown in Figure 4.6. From there, all the functions of the
system could be accessed.

Figure 4.6 Front Page of the VMS

1. Logging in
Similarly to WLC, users should provide a user name and password to be able
to access the administration part of the HMI.

88

The user name and password (by default admin for both) should be entered in
the specified field as shown in figure 4.6.
2. Managing Modems
Authenticated user who has operator privileges can add, remove and modify
the settings of any modem. To access the modems administration main page
which showed in Figure 4.7, the Monitoring Modems link in the
navigation menu should be clicked.

Figure 4.7 Modems Main Page

To add modem: From the modems main page showed in Figure 4.7,
new modem should be clicked. After that, the operator should fill the
new modem form, as showed in Figure 4.8, and then click the submit
button.

89

Figure 4.8 New Modem Form

To modify the settings of a modem: From the modems main page

showed in Figure 4.7, the operator should click on the modem to be
edited. A form, as shown in Figure 4.9, will then showed populated
with the previously entered settings. Operator should modify these
settings to the values wanted and then click the submit button.

90

Figure 4.9 Edit Modem Form

To remove a modem from the system: From the modems main page
showed in Figure 4.7, the operator should open the editing form of the
modem to be deleted, and then click the delete button.
3. Managing Users
Authenticated user who has administration privileges can add, remove and
modify the settings of any user in the system.
To access user management area, the administrator hyperlink in the
main menu in the front page should be clicked, then users. Figure 4.10
shows the users managements main page.

91

Figure 4.10 Users Managements

From the above page, one of the following operations could be done:
Adding user: add user button of the tool bar should be clicked, and
then the operator should fill the appeared list. And click Submit, as in
Figure 4.11. The new user should be assigned to one of the listed
groups.

92

Figure 4.11 New User Form

Modify the information of some user: From the page showed in Figure
4.10, the operator should click the name of the user in concern and then
modify the information existed in the appearing form as shown in
Figure 4.12.

93

Figure 4.12 Editing User Information

Removing user: The operator should click on the name of the user to be
deleted, when the editing form of the user is showed, as in Figure 4.12,
the operator should click on the Delete button.

4.5.1.4 Building Reports

Authorized users can monitor modems, for example, users who are members
in the employee group can monitor all the modems registered in the system.
On the other hand, users who are members in the customers group can
monitor only their own modems (i.e. the modems in which their owner ID is
the same of the user ID).
To monitor a modem, user should click on modem from the list showed
in Figure 4.7. A sample output is shown in Figure 4.13.

94

Figure 4.13 Monitoring and Reporting GUI

5. Browsing Map
Figure 4.14 shows a screenshot of the VMS. The system shows a
geographical map and projecting the modems on it using the real coordinates
which had been found using Global Positioning System (GPS). The system
provides the ability to zoom in and out to any location on the earth. As stated
in the previous chapter, the map is implemented using a free service provided
by Google.

95

Figure 4.14 Modems Projected on Map

4.5.2 RTU Administrator

Configuring the RTU means the process of defining the MTU and the
ID/secret key to be used by the automation program. This information is
stored in a configuration file called rtu.config. The process of configuration
could be achieved by modifying the file manually using any text editor (such
us vi).

4.6 Tested Environments for VMS

The MTU of the VMS was hosted on a shared Web host at the address
(http://hitech-iraq.com/beta). The VSAT modem and the RTU program

96

running on it use the satellite link to access the Internet. Figure 4.15 shows a
network diagram of the implemented system.

Figure 4.15 Network Diagram of the VMS

97

CHAPTER FIVE

Conclusions and Future Work

5.1 Conclusions
During the implementation of the case studies, number of conclusions has
been considered based on the practical results obtained from the implemented
systems and the following are the most important ones:
1. The implemented systems were cost effective solutions compared with
other approaches to build such systems. A basic PC or other low cost
hardware platform (such as embedded computers) could serve as RTU
to the system. Also, the central MTU machine needs relatively very low
resources to achieve its task. The use of the open source software has
even led to a lower cost due to the avoidance of the licensing cost for
the operating system and the servers for both the RTU and MTU.
2. The use of PHP and MySQL for the MTU subsystem had reduced the
total cost of ownership (TCO), the time and cost needed for the
development of the system because of the stability, reliability, ease of
use, and well documentation of these products.
3. Building the system on the top of the selected infrastructure (Linux,
Apache, PHP, MySQL and Perl) which are all proven production
quality software and widely deployed in mission critical applications
have initially made the system very reliable. The system had been
tested in a heavy load environment and proved to be able to work
continuously for a very long time without breakdown.

98

4. The system (MTU, RTU, HMI and the network) is easy to use and
setup. The knowledgebase needed by the system administrator and
operators are very common in the IT field. There are many large
companies that provide courses and certifications which cover most of
knowledge required to setup and use the implemented systems.
5. Because of the use of standard-based security implementation, the
system is very secure. The SSL has provided a high level of privacy
and data integrity. Moreover, the authentication and authorization of
the system is designed to be very strong.

5.2 Future Work

To develop the present implemented work and to achieve a higher level of
usability and effectiveness, the following suggestions are given:
1. For applications which need a faster response, Java Enterprise Edition
could be used for the MTU side. The Java Messaging Service (JMS) is
a viable solution for these kinds of applications. JMS provides a
reliable event driven communication protocol.
2. The browser based HMI could be replaced with Java Web Start
(JAWS). A JAWS is a new application deployment system. It makes it
possible to install software with a single click within a Web browser
that has been enhanced with the Java Web Start plug-in. It transparently
handles complex installation procedures, and it caches software on the
local hard drive so that successive executions of the program are as fast
as possible. That would free the HMI from the limitation of the browser
based application and would make it able to handle more complex
tasks, and keep its simplicity of deployment.

99

3. A hierarchal authorization scheme could be used for a better fine grain

authorization mechanism. The result would be the ability of assigning
an administrators or operators for each group of RTUs.
4. A more sophisticated controlling algorithm could be used for a better
behavior for the WLC system. The suggested method should take in its
consideration the levels of water in the near dams to make the decision
of opening or closing the dam gate.
5. A more powerful analysis tools could be added to the HMI subsystem
to provide additional functionality and even a data prediction for the
WLC system.

100

References
1. Wikipedia,

The

Free

Encyclopedia,

2005.

URL:

http://en.wikipedia.org/wiki/.
2. Communication Technologies, Inc., Supervisory Control and Data
Acquisition

(SCADA)

Systems,

2004.

URL

http://www.ncs.gov/library/tech_bulletins/2004/tib_04-1.pdf
3. Ronald L. Krutz, Securing SCADA Systems, Wiley Publishing, Inc.,
2006.
4. Mike Clayton et. al., A SCADA-Web Interconnection with TCP in Java,
2002. URL:
http://ess.web.cern.ch/ESS/GIFProject/PVSSJava/pvssweb.0.8.pdf
5. Duo Li et. al., Concept Design for Web-based SCADA System, 2002.
6. All

About

Open

Source,

2001.

URL:

http://www.webopedia.com/DidYouKnow/Computer_Science/2005/op
en_source.asp
7. Open Source Initiative (OSI), http://www.opensource.org.
8. B. Qiu, Web-Based SCADA Display Systems (WSDS) for Access via
Internet,

1999.

URL:

http://ieeexplore.ieee.org/iel5/59/18773/00867159.pdf?arnumber=8671
59
9. Kostas Kalaitzakis et. al., Development of a data acquisition system for
remote monitoring of renewable energy systems, 2003.
10. Andrew K. Wright et al., Low-Latency Cryptographic Protection for
SCADA Communications, 2004. URL:
http://scadasafe.sourceforge.net/security.pdf

101

11. Derek C. Ashmore, The J2EETM Architects Handbook, DVT Press,

2004.
12. Visibooks, HTML and Javascript for Visual Learns, First Edition,
Visibppks LLC, www.visibooks.com.
13. Jeremy Allen and Charles Hornberger, Mastering PHP 4.1, Sybex,
2002.
14. Tim Converse et al, PHP5 and MySQL Bible, Wiley Publishing, Inc.,
2004.
15. MySQL AB, MySQL Reference Manual, www.mysql.com, 2004.
16. MySQL AB, MySQL Home Page, URL: http://www.mysql.org.
17. Mohammed J. Kabir, Secure PHP Programming, Wiley Publishing,
2003.
18. Pei An, PC Interfacing, Newnes, 1998.
19. Larry Wall et al., Programming Perl, Second Editionl, OReilly, 1996.
20. Randal Schwartz, Learing Perl, Second Edition, OReilly, 1997.
21. Webmin Documentation Team, Writing Webmin modules, URL:
http://www.webmin.com/modules-printable.html.
22. Mark Mitchell et. al., Advanced Linux Programming, New Riders
Publishing, 2001.
23. Karim Yaghmour, Building Embedded Linux Systems, O'Reilly, 2003.
24. Doug Abbott, Linux for Embedded and Real-time Applications,
Newnes, 2003.

102


SCADA

.
.

.
.
/.
.

. .
.


.

.
.
.
. .
.

) (LAN ).(VPN


.

. .

) (2003

1427
2006