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 June

1427 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: Dr. Firas Abdullah Thweny Al-Saidi (Supervisor) / /

Signature: Name: Date: Dr. Noaman M. Noaman (Member) / /

Signature: Name: Date:

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 Abstract List of Contents List of Abbreviations 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 1.5 Literature Survey 1.6 Work Objectives 1.7 Thesis Layout Chapter 2: Distributed Web Applications and Database Concepts 2.1 Overview 2.2 Types of Applications 2.2.1 Single-tier Applications 2.2.2 Two-tier Applications 2.2.3 Multi-tier Applications 2.3 Elements of a Distributed Application 2.3.1 Presentation Tier 2.3.2 Middle Tier 2.3.3 Data Tier 2.4 Introduction to Database Systems 1 2 3 4 5 6 9 10 12 13 14 Page I III VI

15 16 16 17 18 19 21 22 24 25

III

2.4.1 Introduction to MySQL 2.4.2 Database Concepts 2.5 Security Aspects of Web-Based SCADA System 2.5.1 Data Protection 2.5.2 Authentication 2.7.3 Authorization Chapter 3: Case Study One: Water Level Control 3.1 Introduction 3.2 The Operation of the Overall System 3.3 Master Terminal Unit 3.3.1 The System Database 3.3.2 The RTU Service Provider 3.3.3 HMI Provider 3.3.4 MTU System Requirements 3.4 Remote Terminal Unit 3.4.1 Field Data Interface Device 3.4.2 Parallel Port Interface 3.4.3 Water Level Sensor 3.4.4 Dam Gate Actuator 3.4.5 Programming the RTU 3.4.6 Perl 3.4.7 Local Administration Interface 3.4.8 RTU Automation Software 3.4.9 RTU System Requirements 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

26 27 28 29 32 33

34 35 36 37 39 42 46 46 46 46 48 52 54 54 54 55 59 60 61 68 68 69 70 75

IV

Chapter 4: Case Study Two: VSAT Modems Monitoring System 4.1 Introduction 4.2 System Overall Operation 4.3 Master Terminal Unit 5.3.1 The System Database 5.3.2 RTU Service Provider 5.3.3 HMI Provider 4.4 Implemented RTU 5.4.1 Cross Compilation 5.4.2 Microperl 5.4.3 Traffic Measurement 5.4.4 The Implementation 4.5 Operator Related Instructions for VMS 4.5.1 MTU Administrator 4.5.2 RTU Administrator 4.6 Tested Environments for VMS Chapter 5: Conclusions and Future Work 5.1 Conclusions 5.2 Future Work References

78 78 79 79 80 82 83 84 85 85 86 87 88 96 96

98 99 101

List of Abbreviations
ANSI ARM COTS CPAN CPU DBMS DoS GCC GHz GIS GPL GPRS GPS GSM GUI HMI HTTP I/O ICMP IDE IEEE IP ISDN ISO ISP American National Standards Institute Advanced RSIC Machine Commercial Off-The-Shelf Comprehensive Perl Archive Network Central Processing Unit Database Management System Denial of Service GNU C Compiler Gigahertz Geographical Information System GNU Public License General Packet Radio Service Global Positioning System Global Services Mobile Communications Graphical User Interface Human Machine Interface Hyper Text Transfer Protocol Input/Output Internet Control Message Protocol Integrated Development Environment Institute of Electrical and Electronics Engineers Internet Protocol Integrated Services Digital Network International Organization for Standardization Internet Service Provider

VI

IT JAWS JMS LAI LAN LED MAC MD5 MMI MSL MTU NAT OS PBX PC PLC PSN RAS RDBMS RISC RSP RTU SCADA SHA-1 SMS SMTP SQL

Information Technology Java Web Start Java Messaging Service Local Administration Interface Local Area Network Light Emitting Diodes Medium Access Control Message Digest 5 Man Machine Interface Mean Sea Level Master Terminal Unit Network Address Translation Operating System Private Branch Exchange Personal Computer Programmable Logic Controller Public Switched Network RTU Automation Software Relational Database Management System Reduced Instruction Set Computer RTU Service Provider Remote Terminal Unit Supervisory Control and Data Acquisition Secure Hash Algorithm Short Message Service Simple Mail Transfer Protocol Structured Query Language

VII

SSL TCO TCP/IP UART UI URL VLAN VMS VPN VSAT WAN WLC XML

Secured Socket Layer Total Cost of Ownership Transmission Control Protocol/Internet Protocol Universal Asynchronous Receiver Transmitters User Interface Universal Resource Locator Virtual LAN VSAT modems Monitoring System Virtual Private Network Very Small Aperture Terminal Wide Area Network Water Level Control 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 Type Presentation Presentation navigation, of and information protection and of functionality, user interface Service Attribute

consistency and integrity. Application Logic Shared business policies, generation of business information from data, and protection of business integrity. Data Services Definition of data, storage and retrieval of persistent 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 reuse-shared among multiple

19

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 RAM : Intel Pentium 4 (2.8 GHz). : 512 MB.

Hard Disk Usage : 7 GB for Windows. of the Overall System 5 GB for Linux.

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 7 6 5 4 3 2 1 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 IN8 0 0 0 0 0 0 0 0 1 IN7 0 0 0 0 0 0 0 1 1 IN6 0 0 0 0 0 0 1 1 1 IN5 0 0 0 0 0 1 1 1 1 IN4 0 0 0 0 1 1 1 1 1 IN3 0 0 0 1 1 1 1 1 1 IN2 0 0 1 1 1 1 1 1 1 IN1 0 1 1 1 1 1 1 1 1 GS 0 0 0 0 0 0 0 0 1 Output A2 0 0 0 0 1 1 1 1 1 A1 0 0 1 1 0 0 1 1 1 A0 0 1 0 1 0 1 0 1 1

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; $stts=`in $stts_add`; $stts &=120; $stts /=8;

#status group address #read byte from status port #mask the 3 LSBs #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 a 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


. . .

) 3002(

7241 6002