Thesis

Over the Air Programmable
Stand-Alone Controllers Using

GPRS Technology
Kevin Benjamin Mayer

University ID: u3110766
28th June, 2002
A thesis submitted in part fulfilment of the

degree of Bachelor of Engineering at the
Australian National University
Supervised By: Dr Zbigniew Stachurski (ANU)

Dr Ken Taylor (CSIRO)
Acknowledgements
This project would not have gotten off the ground (without crashing back head first)
were it not for Kens enthusiasm - thank you for believing that this can be done all those
times that I became so sceptical!
Zbigniew has always been there with suggestions and advice - with regards to both
the project and the thesis itself. Thank you for your support.
An extra thank you to Mike Kearney of CMIS fame who was always around offering
extensive advice on electronics. Not to mention his PIC programming help and his LED
board that gave the device a visible face.
Lukas and James - the fellow CMIS students - you have been great to work alongside
and it has been good having people to discuss both technical and non-technical issues
with along the way.
Last but not least, a big thank you to Daphne Bruce of CMIS for taking the time to
proof read my thesis.
Abstract
Supervisory Control and Data Acquisition (SCADA) is a field of constant development and worth billions of dollars around the world as it is used many types of
industries. This project is concerned with creating an extremely low cost device which
can be adapted to many different SCADA applications via some very basic programming, and plugging in the relevant peripherals. Much of the price in some expensive
SCADA applications is a result of using specialised communication infrastructure. By
using existing infrastructure, in this case, the mobile GSM network, not only can price
be kept down, but scalability and the generic nature of the device is maintained.
This project deals with the creation of an inexpensive, yet adaptable and easy to use
SCADA device and infrastructure using the mobile telephone network, in particular, the
General Packet Radio Service (GPRS). The hardware components making up the device
are relatively unsophisticated, yet the custom written software makes it re-programmable
over the air, and able to provide a given SCADA application with the ability to send
and receive control and data signals at any non predetermined time.
CONTENTS
List of Figures
iv
List of Tables
Definition of Acronyms
1 Introduction
1.1 Definition . . . . .
1.2 Motivation . . . . .
1.3 Goals . . . . . . . .
1.3.1 Simplicity .
1.3.2 Price . . . .
1.3.3 Adaptability
1.4 Scope . . . . . . .
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
3
4
4
4
2 Mobile SCADA Today

2.1 Competing Technologies . . . . . . . . . . .
2.1.1 Crossramp . . . . . . . . . . . . . . .
2.2 Related Technologies . . . . . . . . . . . . .
2.2.1 Australias Telerobot on the Web . .
2.2.2 CMIS and Communication Methods
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
8
8
8
3 Project Design
3.1 Theory . . . . . . . . . .
3.1.1 Internet Engine .
3.1.2 Server . . . . . .
3.1.3 GPRS Module . .
3.1.4 Communications
3.2 Design . . . . . . . . . .
3.2.1 Bootloader . . . .
3.2.2 Back End . . . .
3.2.3 Front End . . . .
3.2.4 Database . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
12
15
16
17
18
18
21
21
23
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
CONTENTS
3.2.5
3.2.6
3.2.7
Inter-module Communications . . . . . . . . . . . . . . . . . . . .
External Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . .
Software Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Implementation
4.1 Equipment . . . . . . . . . . . .
4.1.1 Development Computer
4.2 Method . . . . . . . . . . . . .
4.2.1 Back End . . . . . . . .
4.2.2 Front End . . . . . . . .
4.2.3 SCADA Engine . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
26
27
29
29
30
31
31
32
32
5 Results
35
5.1 Degree of Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Sample Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6 Discussion
6.1 Development and Implementation Choices .
6.1.1 Server Model . . . . . . . . . . . . .
6.1.2 Connectivity for the SCADA Engine
6.1.3 Compiler Software . . . . . . . . . .
6.1.4 User Program Storage . . . . . . . .
6.1.5 Cost Versus Robustness . . . . . . .
6.2 Communication Protocols . . . . . . . . . .
6.2.1 Internet Engine Back End . . . .
6.2.2 Front End Back End . . . . . . .
6.3 Limitations Imposed on User Programs . . .
6.3.1 Memory Usage . . . . . . . . . . . .
6.3.2 Stack . . . . . . . . . . . . . . . . . .
6.3.3 Interrupts . . . . . . . . . . . . . . .
6.3.4 Low Power Mode . . . . . . . . . . .
6.4 Enhancements to the SCADA Engine . . . .
6.4.1 Interrupts . . . . . . . . . . . . . . .
6.4.2 Program Size . . . . . . . . . . . . .
6.4.3 Code Protection . . . . . . . . . . . .
6.4.4 Security . . . . . . . . . . . . . . . .
6.5 Commercial Potential . . . . . . . . . . . . .
6.5.1 Irrigation Monitoring . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
37
39
39
40
41
42
42
44
45
45
46
46
46
47
47
47
47
48
48
49
7 Conclusion
50
Appendices
54
A Communication Protocols
54
A.1 Server SCADA Engine . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.2 Front End Back End . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.2.1 XML Message To Device . . . . . . . . . . . . . . . . . . . . . . . 55
ii
CONTENTS
A.2.2 XML File For Upload . . . . . . . . . . . . . . . . . . . . . . . . .
B Source Code
55
57
C Memory Overview
58
C.1 Program Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
C.2 Data Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
D Hardware Schematics
60
D.1 The Internet Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
D.2 Dontronics DT001 PIC Programmer . . . . . . . . . . . . . . . . . . . . 63
E Project Plan
64
iii
LIST OF FIGURES
1.1
1.2
Overview of the SCADA Engine in a Production Environment . . . . . .

Scope of the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
3.1
3.2
3.3
Pin Connections Between the Programmer and the Internet Engine . . .

Module Interaction Using a Server as a Contact Point . . . . . . . . . . .
Logical Interaction Between the Modules . . . . . . . . . . . . . . . . . .
15
15
25
6.1
Module Interaction for a no server Model . . . . . . . . . . . . . . . . .
38
C.1 Memory Map of Program EEPROM Usage . . . . . . . . . . . . . . . . .

C.2 Memory Map of the External EEPROM Usage . . . . . . . . . . . . . . .
58
59
D.1
D.2
D.3
D.4
D.5
D.6
D.7
60
61
61
62
62
63
63
The Internet Engine and its Dimensions . . . . . . . . . .

Schematic - Serial Connection to the PIC16F877 . . . . . .
Schematic - PIC16F877 and its Connections . . . . . . . .
Schematic - S7600A and its Connections . . . . . . . . . .
Schematic - Serial Connection to the S7600A . . . . . . . .
Schematic - All Other Components . . . . . . . . . . . . .
The Footprint of the Dontronics DT001 PIC Programmer .
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
LIST OF TABLES
2.1
Comparison of Mobile Telephony Based Communication Methods. . . . .
3.1
Format of Database Table Used to Log Messages
. . . . . . . . . . . . .
24
4.1
Development and Production Software Required. . . . . . . . . . . . . .
30
6.1
Cost per 24 Hours per Device Due to Pinging. . . . . . . . . . . . . . . .
42
A.1 Communications Protocol - Initial Connection of SCADA Engine to Server. 54

A.2 Communications Protocol - Uploading a Program to a SCADA Engine. . 54
A.3 Communications Protocol - Front End Back End. . . . . . . . . . . . 55
DEFINITION OF ACRONYMS
ASCII
American Standard Code for Information Interchange. The ASCII character set defines the bit patterns used to denote alpha-numeric characters,
as well as control characters and other special symbols.
bps
Bits per second. A bit is a binary digit - the smallest quanta of information
in the digital world.
CMIS
The CSIRO Mathematical and Information Sciences Division. CMIS provided much support for this project as it fell into one of their research
areas.
CPU
Central Processing Unit. This is essentially part of a computer that does

the arithmetic logic. It is common used to refer to a microchip as a CPU.
CSIRO
The Commonwealth Scientific and Industrial Research Organisation.
DB-25
A 25 pin communications connector used for serial and parallel protocols

(commonly used on printer port plugs on PCs).
DB-9
A 9 pin serial communications connector (commonly used as the COM

port plugs on PCs).
DTD
Document Type Definitions. A DTD is a document that defines the allowable format of any SGML (Standard Generalised Markup Language)
document.
EEPROM
Electrically Erasable Programmable Read Only Memory. EEPROM retains its data even when the power supply is switched off. Data is erased
from EEPROM by exposing it to an electrical charge.
FTP
File Transfer Protocol
GPRS
General Packet Radio Service. This is a packet switched communication

protocol that utilises the GSM mobile phone infrastructure.
vi
GSM
Global System for Mobile Communication. This is the digital mobile communications infrastructure used in Australia and in many other countries
around the world.
HTML
HyperText Markup Language - the language used to describe web pages.
IO
Input and Output
IP
Internet Protocol. IP is a packet switched protocol which forms the basis

of data transmission on the Internet.
ISDN
Integrated Services Digital Network. ISDN lines are used by many companies for data and/or multiple voice line connections.
ISP
Internet Service Provider.
ISR
Interrupt Service Routine. This is a special routine located at the interrupt

vector and is called whenever an interrupt occurs. It determines which
interrupt occurs, and then passes control to the corresponding interrupt
handler.
K or k
Kilo is used as a prefix in computer terms to mean 1024 of ... Throughout

this document program memory size is described as X K words, meaning
that X 1024 words can be put in program memory. One word is the size
of a single instruction. On the PIC16F877 a word is 14 bytes and thus 1K
word takes up 1.75KB.
KB
KiloBytes. This is a commonly used abbreviation in computing, where

one kilobyte = 1024 bytes.
LAN
Local Area Network [of computer].
LED
Light Emitting Diode
NAT
Network Address Translator. A node on the Internet that acts as the sole
gateway to other nodes with private IP addresses (as defined by RFC1661).
Traffic is routed by making data to and from the private nodes appear to
other nodes on the Internet as though it is really to and from the gateway.
PABX
A telephone exchange operated within an organisation, used for switching

calls between internal lines, and between internal and PSTN lines.
PAP
Password Authentication Protocol is a popular authentication method

used by PPP.
PPP
Point to Point Protocol. This is a protocol used to provide a means of

communication between two nodes. TCP and IP can use PPP for transport.
PSTN
Public Switched Telephone Network. The standard landline telephone

network.
vii
RAM
Random Access Memory. This is a form of re-programmable memory that

can be used for data or code storage. RAM requires a power supply to
maintain its data. On the PIC16F877 RAM is used for data.
RS-232
A common serial communication protocol.
SCADA
Supervisory Control And Data Acquisition.
SIM
Security Identity Module. This is a smart card used in mobile phones to

identify the phone to the network provider.
SMS
Short Message Service. Short text messages can be sent between digital
mobile phones and can comprise of up to 140 bytes of data.
SQL
Structured Query Language. SQL is a popular language used for querying

and manipulating information in databases.
TCP
Transmission Control Protocol. This is the primary connection oriented

protocol used on the Internet. It runs above IP.
XML
eXtensible Markup Language is a method of encapsulating data in a way

which is independent of the data it contains. It is human readable and
easily analysed by software.
viii
CHAPTER 1
Introduction
1.1
Definition
SCADA, Supervisory Control And Data Acquisition, is a relatively simple concept,

and although many people are unfamiliar with it, they make use of it on a daily basis. As
a consequence of its every day usage, and applicability to all kinds of practical situations,
it is an important field of study.
Supervisory Control is the act of remotely controlling something by choosing the
ends, without having to be concerned with the means of how that ends is achieved. For
example, when driving a car with cruise control one may select a speed of say 70km/hr
- this is the supervisory control aspect. Once the speed is selected, the cruise control
manager applies throttle and brakes accordingly to achieve and maintain that speed.
The exact details of how this is achieved is of no concern to the driver. This supervisory
control, experienced by many people daily, shows how the net result is chosen without
having to be concerned with the means for achieving it.
Data Acquisition is simply the collection of any kind of data. One example of data
acquisition that companies use daily is web sites on the world wide web that track
who accesses which pages on a given site, and for how long. The data is logged in
the companys web logs (whether it is analysed or not) and it keeps track of all users
activities on that site. The web server acquires data.
Putting it together, supervisory control and data acquisition is used to describe a
system where both data acquisition and supervisory control are performed. A prime
example, again experienced by many people without noticing, is a back to base home
alarm system. When set, the system monitors the house for intruders - it acquires data.
If and when the alarm is tripped, it places a phone call to the monitoring station to let
it know that the house has been broken into and it transmits details as to which sensor
1
CHAPTER 1. Introduction
1.2. Motivation
in the house tripped, and at what time.

Mobile Supervisory Control And Data Acquisition (henceforth referred to as Mobile
SCADA) is the use of SCADA with the mobile phone network being used as the underlying communication medium. As already mentioned, most back to base home alarm
systems use the public switched telephone network (PSTN) for communication. Were
they to use a mobile phone instead to place the call, they would fall into the mobile
SCADA category. Apart from the PSTN, other communication mediums are used for
SCADA, ranging from satellite communication to special, custom laid cables.
1.2
Motivation
Like many technological developments, the drive behind improvements in SCADA

is economics - to create something that is as capable as an industrial device, but a lot
cheaper. There exist many commercial grade SCADA devices whose costs run into the
tens of thousands of dollars to build and operate. They perform the required job very
well, and can often be adapted to many different situations. Such devices are suitable
for large companies with money to spend. For example, a water supply company would
have a number of controllers around a city to monitor water levels and water quality
in various dams and reservoirs. They would also be able to control the flow of water
in and out of these reservoirs. All this would be done via a control centre rather than
having people move around to each site on a regular basis. A capital outlay of millions
of dollars would be warranted in such a situation given the long run benefits of such a
system.
Often however, the cost of a SCADA system far outweighs any long term benefits.
For example, a wheat farmer could very well make use of a system that monitors the
dampness of the soil at various positions around the farm, and irrigate the land accordingly. This would obviously be beneficial to the farmer as it would save him walking
around the farm on a regular basis to check soil dampness and then to irrigate accordingly. It would ensure only the necessary amount of water would be applied to the soil,
leading to very little waste. A SCADA device for this situation would save him time and
money. If the cost of sophisticated devices could be reduced, then the cost-benefit analysis in many situations would change, potentially leading to SCADA devices suddenly
becoming worthwhile in many situations in which they were previously too expensive.
The other kind of existing device is cheap, but inflexible. Such inexpensive SCADA
devices are custom built for a particular use, but cannot be easily adapted to different
tasks.
Creating a low cost, and relatively flexible SCADA device that can be applied to
many different situations could have a significant commercial potential. It would save
companies who use expensive systems a lot of money, and would bring SCADA into the
2
1.3. Goals
reach of many businesses that previously found SCADA too costly.

The motivation behind using the mobile infrastructure for communication is twofold.
The mobile communication infrastructure exists, is very robust, reliable and covers
most populated areas. This eliminates the need to create and build a custom
communications infrastructure - saving potentially millions of dollars.
Accessing the cellular mobile network can be cheap depending on the required data
transfer. Basic access costs only a few dollars a month in addition to the cost of a
handset or modem which can be as low as $200.
General Packet Radio Service (GPRS) was chosen as the specific mobile communication protocol to use as it provides an always on-line Internet connection without any
time based charges.
1.3
Goals
The aim of this project can be summed up with three key goals - the creation of a
simple, inexpensive, over the air re-programmable SCADA device that will use GPRS
as its basis for communication. These three elements are described below as simplicity,
price and adaptability:
1.3.1
Simplicity
Not only did the device need to be relatively simple to create given the limited time
and resources, but it was very important for it to be simple to use. The system should
be aimed at companies with varying levels of technical ability - not just those with
dedicated electronics or SCADA experts. This meant that the device would need to
be relatively simple to use and maintain. A level of abstraction could be introduced to
ensure that users of the device would not need to be familiar with the microprocessor
or other pieces of hardware used on the board. Similarly, the sending and receiving of
control signals and data should be handled by the device in a seamless manner such
that the end user does not need to be concerned with, for example, how to ensure that
control signals are received in the same order they are sent.
As much user interaction as possible would be done via the web. By having users
interact with a service, rather than managing devices themselves, much complexity of
operations can be hidden, allowing the users to concentrate on the application and not
the technology. This had to be done in such a way that although the device would be
simple to use, no compromises would be made on functionality.
1.3.2
1.4. Scope
Price
An important goal of this project was to make the use of SCADA more wide spread,
and more easily available to companies and research institutions that previously found
the cost too prohibitive. This means being able to manufacture a device at a cost much
lower than existing sophisticated SCADA devices. A reasonable price for such a device
is relative to the company purchasing it and application for which it is being used. A
given company is willing to spend money if the cost-benefit analysis shows the long term
benefit to outweigh the short term cost. Since there is no magic price, merely creating
a substantially cheaper SCADA device, would make the technology less restrictive costwise for many more companies.
The initial price goal was to create a device which would cost less than $1,000, though
by the end of the project it was clear that the complete device could manufactured and
sold for no more than $500! This is extremely low relative to existing sophisticated
SCADA devices which can cost upwards of $10,000. Although potentially a lot less
specialised and sophisticated than such devices, this device could be applied to many
situations where it was previously too expensive to use SCADA.
1.3.3
Adaptability
By creating a single device that can be used in many different circumstances, we

eliminate the need for each individual user to create their own device from the bottom
up. A generic device that can be adapted to a particular need very easily was required.
In other words, something that can be adapted to a given situation by a person who is
not necessarily an expert in the SCADA or electronics fields.
The device should have only the bare essentials, allowing each user to modify it for
their particular use. Modifying the device consists of attaching any peripherals to the
device (eg., a sprinkler valve and a water level sensor) and writing a small application
to define what the device is to do (eg., open the valve whenever the water level drops
below a certain point). The device would also provide users with a generic means of
sending and receiving data or control signals to and from the device. Building on the
simplicity goal, the user interface is implemented as web site.
1.4
Scope
This project is limited to part of the infrastructure related to mobile SCADA. The
aim is to create a prototype system incorporating a device - aptly named the SCADA
Engine - which can then be used for mobile SCADA applications. The SCADA Engine
does not implement a mobile SCADA application, though a very simple application to
demonstrate the capabilities of the device will be built.
4
1.4. Scope
A depiction of the various connections and interactions between parts of the system,
and how data flows from the user to their device is given in Figure 1.1 to provide a
context for the project. It shows the various connections and data flows between different
sections of a complete SCADA system relying on the infrastructure and technology this
project is focused on.
The Internet
network
providers
GPRS/net
gateway
GPRS capable
mobile phone
SCADA
Server
network
or dialup
connection
PPP/serial
link
I/O channels to peripherals

(sensors, etc.)
SCADA
Engine
User wishing to install a

new program or monitor the
device simply needs a PC with
a web browser connected to
the Internet.
Figure 1.1: Overview of the SCADA Engine in a Production Environment

Figure 1.2 defines which logical components of the system are within the scope of this
project. This is a simplistic breakdown of the system depicted in Figure 1.1, and gives
an indication of how an end user will implement an end to end SCADA application.
Sensor
(or other device)
Virtual commumication
channel for user
User/application to
application
send/receive data
& control device
Internet
Engine
Server
subsystem
Scope of project
Figure 1.2: Scope of the Project

On the one hand, a sensor, or controller for a given application will still need to be
connected to and interfaced with the SCADA Engine. On the other hand, the user (or
an application) will need to interface with the server in order to send or receive and
process messages (data or control signals).
5
CHAPTER 2
Mobile SCADA Today
2.1
Competing Technologies
There is very little in the way of technologies that are aimed at achieving the same
goal as this project. Although many companies are actively working on SCADA technology, information on only one company which is working on a GPRS mobile SCADA
solution could be found.
2.1.1
Crossramp
Company Overview
Unidata Group Holdings Ltd., is a global company based in Perth, Western Australia.
Their focus is on the development of a range of environmental monitoring apparatus.
They sell sensors, data loggers, communication solutions, software and peripherals all
aimed at monitoring agricultural and environmental parameters. One of their latest
ideas is Crossramp[12]. The Crossramp technology is very similar in concept to the
SCADA Engine, but there are a few differences.
Product Overview
Crossramp will allow users to have data logged from a remote site and downloaded
to their computer on a regular basis. The product is sold as a device, together with a
subscription service. From the users point of view, the device, called an XRT, connects
to standard data-loggers which log data as per usual. The XRT has an integrated
communications module which allows Unidata to transfer the data from the XRT to
their servers on a regular basis, thus creating a link between the data logging and the
data storage on the servers.
6
CHAPTER 2. Mobile SCADA Today
2.1. Competing Technologies
The data on the Crossramp servers will be fully dependent on what is being monitored
and the user monitoring it. The user will then be able to retrieve the data from their
servers by FTP, a custom thin client application, email or some other means.
According to information available on the Crossramp web-site[12], the first of the
units will become available from June 2002. However, due to the fact that as of June
there are still no Crossramp products available, it is not possible to fully evaluate and
compare them to the SCADA Engine.
Product Details and Comparison
The Crossramp technology appears to provide a very similar service to the SCADA
Engine. However, from the description available from Unidata, it appears that the communication and user program are independent of each other. The XRT simply collects
data output from the data-logger and sends it to the Unidata servers as appropriate
(either at a predefined regular interval, or when a certain trigger value is received). The
SCADA Engine allows for program logic in the users code to determine when data is
sent to the server, rather than having to decide a priori.
The communications technology offered is based on either GPRS or satellite communication. The GPRS unit is obviously more similar to the SCADA Engine, however the
satellite option is functionally identical. The difference being that instead of transferring
data through GPRS over the GSM network, it uses the Globalstar satellite network1 to
transfer the data to the Unidata servers. This advantage is apparent as there is greater
coverage with Globalstar than with GSM.
Software will be provided to subscribers which allow them to individually manage
and configure their XRTs[29]. This software is analogous to the web interface that will
be provided to users administering their SCADA Engine. With Crossramp, the method
of data storage is totally unknown to the user. Users will retrieve their data (that
has been sent from their XRTs) via FTP2 , email, or simply via the software provided
by Crossramp. The SCADA Engine system however provides a mechanism for users to
directly query the database where the data from their SCADA Engine will be stored. By
manipulating the SQL users will be able to retrieve all messages from their device in XML
format, which can then be manipulated using XML style-sheets and transformations.
Unfortunately, as previously mentioned, a detailed comparison between the Crossramp products and the SCADA Engine is not possible since the XRTs are not yet
available.
1
2
See http://www.globalstar.com for further details.

File Transfer Protocol
2.2
2.2. Related Technologies
Related Technologies
2.2.1
Australias Telerobot on the Web
One of the very first SCADA systems that used the Internet as the communications
medium is the web controlled robot created by Dr Ken Taylor at The University of
Western Australia as part of his PhD[27]. The robot was controlled by users via a web
interface and was able to pick up and move blocks around a given area. The system
demonstrated how the Internet could be used as both a feedback mechanism and a way
to control something. The project was a huge success and work is still being done on
it today[1]. The concepts of supervisory control and data acquisition are illustrated
superbly by the Telerobot. A user, via their web browser can specify a coordinate for
the robot to move to, and then, through a web-cam image, see the robot go there.
2.2.2
CMIS and Communication Methods
The communication technology that has been investigated at CMIS is based on the
telephone infrastructure, with a particular emphasis on mobile telephones. All SCADA
applications have a basic requirement of communication between the device and a human
controller or monitor - be it the transfer of acquired data, or the sending of control
signals. There is a range of complexities that this information can consist of - from
basic on/off, 1 bit communication, to detailed control which involves multi-byte data
transfer.
A summary of the four telephony related communications methods investigated by
CMIS is given in Table 2.1, following which is a detailed discussion of the three alternatives not used for this project. In the table, Always online refers to the ability of a
node to communicate with its peer at any non predetermined time.
Method
Caller ID
SMS
Data calls
GPRS
Cost
per KB
$0.00
$1.83
$0.01
$0.02
1KB transfer
time
2 hrs, 15 mins3
40 seconds
1 second
1 second
Full
duplex

Reliable Always
online

4

Table 2.1: Comparison of Mobile Telephony Based Communication Methods.
Tests show that it takes approximately 2 seconds between dialling a number, and the receiver
ringing. Using a single receiving telephone, this gives a data rate of 1 bit per 2 seconds.
4
For continuous communication, either the call must be established constantly, or both peers must
be able to act as both a client and a server.
Single Bit Communication

The simplest technology is a single bit transfer which occurs by calling a particular
phone number. This method is not specific to mobile telephones, but does require the
caller ID feature to be enabled on the receiving line, and the calling telephone number
to not block their ID.
CMIS has allocated a bank of phone numbers on its PABX system which are used
solely to listen for rings. A computer is connected to the PABX system which notifies
the computer (the protocol with which this is done is irrelevant to the discussion) when a
phone on the PABX system rings, and the telephone number that is placing the call. The
computer maintains a database that matches receiving telephone numbers (the callee) to
caller IDs and corresponding actions5 . The actions take the form of an HTTP request,
sending an SMS message, or sending an email - but theoretically can be extended to be
anything that a computer can be configured to do.
Using a single receiving number, a single known outcome can be configured to occur
for any given calling number - this is the single bit that is communicated. A bank of
receiving numbers allows multiple bits to be transmitted by calling certain combinations
of telephone numbers.
There are two important points to note about this communication method.
1. Since it relies on caller ID which is made available as soon as the telephone rings,
no phone call is ever established. Once the caller hears the ringing on the other
side, they may hang up. Thus, apart from telephone line rental, there is no ongoing
cost, irrespective of the extent of system utilisation.
2. If the system is set up to perform a particular action for a given caller/callee
pair, it by no means prevents the same destination phone number being used to
perform a different action as a result of a call from a different caller. Using a
normal telephone line, high utilisation could lead to engaged signals instead of
calls getting though. However, if a PABX is used (connected to an ISDN line
for example), notification of calls - which includes the caller ID of the caller - is
recorded irrespective of whether the particular number is busy or not.
A practical example of this communication method is a vending machine which
dispenses water bottles based on receiving a call. As demonstrated by CMIS at the
Wireless Infocomms 20016 exhibition at Darling Harbour in Sydney, a vending machine
with a computer connected to a telephone line7 can be set up to dispense drinks on
5
An implementation of this is available at http://mobile.act.cmis.csiro.au/sms/editActions.asp

See http://mobile.act.cmis.csiro.au/sms/vending/sydney.asp for further details.
7
The computer and telephone connection do not necessarily have to reside in the same location as
the vending machine, however there does at the very least need to be a communication link between
the computer and the vending machine.
6
request. A telephone number is displayed on the vending machine, which when called
will dispense a drink bottle. The server logs the caller ID of the person calling the
vending machine, and by coordination with the mobile telephone company, the charge
of the drink can be added to the users telephone bill.
SMS Messages
A more sophisticated communication method that involves much more data transfer
is SMS messages. SMS messages can be sent between GSM mobile telephones and
provide an asynchronous (but without guaranteed delivery) method of communication.
Although bi-directional, meaning it can be used for both sending control signals and
receiving data signals, communication is not full duplex. Although each message is
limited to 140 bytes, long messages can be broken up into multiple messages. Each
message attracts a cost of 25c8 .
A computer connected to a mobile telephone/modem via a serial cable and using
the AT and AT+ command set can be used to automate SMS message sending and
receiving. Inbound messages can be parsed by a program on the computer and acted
upon. Similarly, a message can be assembled on the computer and sent to mobile
telephone as required.
Data Calls
A more comprehensive communication method which allows for heavy data traffic
is establishing a data call between two telephones, analogous to a data call between a
home personal computer and an Internet service providers server. So long as the call is
established, data can be transferred.
One can attach a mobile telephone to a SCADA controller and use a PC with a
modem to establish a remote connection with the device. While the connection is established, data transfer is bi-directional and can be full duplex.
Australian telecommunication companies charge users based on the duration of the
connection. This factor alone makes this communication method impractical for systems
which need to constantly be in contact with the controller or monitoring as a continuous
connection can easily exceed $200 per day9 . However, this method is particularly useful
when large data transfers are required over short periods of time, and connectivity is
not required during other times. One could circumvent this by giving both sides the
ability to act as a server and a client. Thus a continuous connection would not need to
be maintained, but a host could connect to the peer when required, transfer data, and
8
This is the average SMS fee amongst mobile carriers in Australia as of May 2002.
As of June 2002, an average call cost of less than about 15c per minute is not available in Australia.
Though even at 15c per minute, the cost per day becomes $216.
9
10
then disconnect. This however, would mean greater logic sophistication in the SCADA
device.
CMIS has implemented the data call method for one way communication between
two weather stations (attached to GSM modems) and their server. On a regular basis,
a connection is established between each weather station and the server to download
the latest data which is then made available via a web interface10 . If the user does not
require real-time data, then continuous communication is not required, and the data call
method would be well suited to this application.
10
For further details, see http://mobile.act.cmis.csiro.au/weather/
11
CHAPTER 3
Project Design
3.1
3.1.1
Theory
Internet Engine
Hardware
The Internet Engine is circuit board manufactured by Fred Eady of EDTP, or can
easily be built from its individual components as explained in the Assembly Manual[6].
The board contains the following components which are significant to the project:
A PIC16F877 microprocessor
Seiko S7600A - a hardware implemented TCP/IP stack
Microchip 24LC256 - 32KB EEPROM
Two RS232 serial connections - one to program the device and one to provide a
serial link to a modem (or other device)
The PIC microprocessor is the brains of the whole system. The S7600A provides
a means of using PPP and TCP/IP functionality without having to implement it in
software. The advantage of this is two fold; firstly it is a lot faster than software
can possibly be. Secondly, a TCP/IP stack would require a significant portion of the
available memory on the PIC and would utilise otherwise available processing time. The
PIC resources are too scarce for this.
The available data memory on the PIC itself is minimal, only 256 bytes of EEPROM
(plus 368 bytes of RAM). The 24LC256 will provide user programs with additional space
for data storage. This will be particularly useful for data acquisition applications where
12
CHAPTER 3. Project Design
3.1. Theory
some data will need to be stored locally before transmitting to the server. Some parts of
the external EEPROM are reserved for special use. The last 512 bytes contains various
parameters used by the software such as the IP address of the back end, the port to
connect on and the GPRS username and password. Additionally, the first four kilobytes
are reserved for sending and receiving messages as detailed in section 3.2.7. A complete
map of the external EEPROM is shown in Appendix C.2.
Software
The software that resides on the Internet Engine formed the core of the project. All
other work was based around getting the software working. As can be derived from
the adaptability goal discussed in section 1.3.3, some kind of a bootloader would be
required for the Internet Engine. In addition the installing and running new programs
it would also have to provide some minimal operating system functionality specifically
geared to wards SCADA applications - such as message sending and receiving. Since
the bootloading functionality is the most important part of the software, it is henceforth
collectively referred to as the bootloader.
The idea was to write a bootloader that would run programs that could be downloaded to it over the Internet. In addition to this requirement, unlike a traditional
bootloader which, once it has given control to a program, has no more control of the
processor until it is restarted, it would need to somehow still listen for a new incoming
program so it could install and run that. The reason for this is that since we wanted a
device which could be reprogrammed without having to be in physical proximity to it,
there would be no way to force a restart and hence pass control back to the bootloader.
Working from some basic requirements such as this, other issues that had to be dealt
with became evident. The primary requirement, as well the consequential secondary
requirements follow.
Primary Requirement
Be able to load programs over the Internet. Any program loaded should be run
immediately even if another program is already running.
Secondary Requirements
TCP functionality is required in order to load programs over the Internet.
The bootloader needs to be able to make TCP connections as well as
being able to deal with disconnections.
In order to be able to load a new program in when another program
is already running, the bootloader needs to constantly be resident in
memory. This is achieved via the use of an interrupt in the bootloader
which can be triggered on any kind of TCP event (including the download
13
3.1. Theory
of a new program). The bootloader also has to ensure that no downloaded

code overwrites any of the bootloaders code space.
The bootloader is sophisticated relative to the functionality of the chip. Since there
is no multi-tasking environment running on the PIC, there needs to be some way to stop
a user program from running and run the bootloader when certain events occur. This
is necessary so that new programs can be uploaded when desired, messages can be sent
to the device, and most importantly, to ensure that the device never becomes totally
inaccessible due to a user program not voluntarily handing control to the bootloader.
All this is achieved using interrupts as described in the operations subsection of section
3.2.1. Since the events that need to be trapped are TCP events (eg., a new program
being sent from the server for upload), the PIC gets its interrupts via a pin connection
with the S7600A which generates interrupts on pre-configured events.
PIC Programmer
Although the Internet Engine comes with a pre-installed bootloader, it is not required
in the final working system. The bootloader provided is there so one can program the
Internet Engine without the need for a programmer. The bootloader allows users to
upload programs via a serial cable connected to a PC using a basic terminal program.
This is useful for testing, however, for production, this bootloader is simply a waste of
space in memory. To get rid of it, a PIC programmer is required. The pins required to
program the PIC16F877 are all brought out to the edge of the board. They take the
following inputs;
data
clock
programming voltage
base voltage
ground
Using the Dontronics DT001 programmer1 and PIC programming software[10] one
can program the project code over the bootloader that comes with the hardware.
When connecting the five pins from the programmer to the relevant pins on the
Internet Engine, one must ensure that all of the connector wires are less than 2-3 inches
long each. If the wires are too long, the added capacitance will cause too much of a lag
in the programming pulses, and the programmer will not work on the Internet Engine
1
Available from http://www.dontronics.com/dt001.html
14
3.1. Theory
chip. Figure 3.1 shows the connection between pins 1-5 of J1 on the programmer (see
Appendix D.2 for a schematic of the programmer board) and the relevant 5 pins on the
Internet Engine (which are all brought out to the side of the board).
Side of the Internet
Engine
PIC Programmer
J1
1
Ground (GND)
Operating voltage (Vcc)
Programming voltage(Vpp)
Data input (PGD)
Clock input (PGC)
Figure 3.1: Pin Connections Between the Programmer and the Internet Engine
3.1.2
Server
A server needs to be implemented as the central contact point for both devices, and
users. This is depicted in Figure 3.2.
Figure 3.2: Module Interaction Using a Server as a Contact Point

A single point of contact for the devices means a single configuration can be used for
all devices. More importantly, the fact that a server exists, and is based on substantial
hardware (a PC as opposed to an Internet Engine), means that as much functionality as
possible can be transfered from the SCADA Engine to the server - leading to a smaller
and less complex bootloader. Not only is it cheaper and easier to run complex software
on a standard PC compared to a micro-controller, but it is a lot easier and cheaper to
15
3.1. Theory
debug an application on a PC, than it is to debug or change code on a micro-controller

which may be thousands of kilometres from ones office!
The server also provides users with a single point of contact for all their devices via
well known means - such as the world wide web. Any interaction between a user and
their device(s), or any data that is sent back from a device, is always handled by the
server. In other words, the server simply acts as a conduit between devices and users.
3.1.3
GPRS Module
A GPRS telephone or modem is required to provide the device with a continuous

connection to the Internet. Naturally an account with a suitable telecommunications
provider is required too. The Internet Engine communicates with the telephone over an
RS-232 connection using standard AT2 and AT+3 commands in order to establish the
connection Internet connection. Once established, the telephone effectively tunnels TCP
through a PPP connection giving the device a connected to the telephone an Internet
connection (similar to a PPP connection between a PC and an ISPs server providing
the user with an Internet connection).
Since one of the aims of this project is to create a device which is contactable at any
given time - in other words, have a continuous online presence - it was necessary to use
either a data call or GPRS. Since a constant online presence with a data call would cost
hundreds of dollars a day and data transfer would likely occur for only a fraction of that
time, GPRS was the obvious choice.
The GPRS module used for this project is the Motorola Timeport P7389i.
GPRS Background
As specified in the GSM phase 2 standard[8], GPRS provides packet switched access
to the Internet using the GSM mobile infrastructure. A voice or data call placed on a
GSM network occupies one slot for the duration of the call. GPRS on the other hand
only takes up bandwidth when data is being transmitted or received such that a slot
not being used for a voice call may be shared by tens of GPRS users simultaneously
using time division multiplexing. During a voice call, when both parties are silent, the
slot is still being used, even though no useful information is being transmitted. Using
a GPRS connection to browse the web for example, would only utilise bandwidth while
actually loading pages, not while the user reads a loaded web page. Telecommunication
providers charge GPRS users based on the amount of data transmitted, not the amount
of time online.
2
The AT commands are a standard set of ASCII text based, line oriented commands that computers
use to communicate with modems.
3
The AT+ command set is an extension to the AT command set used for communication with mobile
telephones
16
3.1. Theory
GPRS is similar to SMS in that it is a communication method relying on the GSM

network and utilises bandwidth (and costs) based on data, not time. GPRS provides
users with reliable connections, and a continuous online presence in the same way as a
PC connected to a LAN has continuous access to the other computers on the network,
but only utilises bandwidth when it is transmitting or receiving data.
It was discovered that there are many limitations on the Internet over GPRS connection provided by Telstra, the chosen provider. The main limitation is that access is
provided through a network address translator (NAT) in accordance with the specifications of RFC1661[19]. The connecting device is assigned a private IP address which
is not visible to other computers on the Internet. When the device initiates a connection outwards, Telstras gateway acts as a conduit for the connection and tunnels the
connection, making it appear to the outside world as though it came from the gateway
itself. The net effect is similar to that of using a proxy server.
The NAT, however, restricts other nodes on the Internet initiating connections inwards towards one of these private nodes behind the gateway4 . By assuming that these
limitations could be put in place by any GPRS provider, an attempt was made to solve
any problems which arose as a consequence of them, in such a way that they would work
in these restricted situations, as well as in a situation where no such restrictions existed.
The solution was simple, to ensure the connections were always initiated by the device
behind the NAT.
3.1.4
Communications
There are a number of communication interfaces in the system, they are between the
following pairs of modules.
User and Server - This is implemented using an interface that most users would be
familiar with - the web.
Front end (web) and back end server - A basic text based TCP protocol was created for this purpose.
Back end and each Internet Engine - TCP over GPRS will be used. Some background on GPRS and how it is used is given below.
Each Internet Engine and attached peripherals - Depending on the attached peripheral, this may be in the form of RS-232 or more basic digital or analogue IO.
bootloader and user software - Implemented via system calls and common C header
files as described in section 3.2.7.
4
Although there are many ways around this, Telstra severely restricts such access.
17
3.2
3.2. Design
Design
Throughout the design (and the implementation) many constants are used. Most of
these constants are referenced using a name and not by their specific value in order to
enhance readability and understandability. The actual value of many of these constants
is irrelevant to the operation of the system, so long as the same value is used for the same
constants in all modules. This is necessary in order to ensure communication protocols
are understood by all communicating parties.
3.2.1
Bootloader
The bootloader, the software that is to reside on the PIC chip on the Internet Engine
is the key component of the system. This piece of software was needed to fulfil all of the
design requirements, without exceeding the operational limitations which are defined
below.
Requirements
The design requirements for the bootloader stem from the theoretical goals set out
in section 3.1.1. This is what separates this device from other SCADA devices.
Provide a method to reprogram the microprocessor on the fly. This is essentially
the definition of a bootloader.
Accept new programs over the Internet at any time. In other words, a new program
should be able to be uploaded to the system at will. As a consequence of this
requirement the bootloader would necessarily have to be able to communicate
over TCP.
Allow the user program access to as many of the hardware resources as possible.
ie., It would be pointless if the bootloader used all of the timers and interrupts,
leaving none for the user program.
Provide a method for the user program to send and receive messages. This means
that there would be no need for the user to implement the raw socket functionality
themselves as it would be handled by the bootloader.
Constraints
Since the total program memory space on the PIC is only 8KB, the bootloader
should take up as little space as possible such that there is enough space to load a
useful5 user program. The ultimate goal would be to keep the bootloader to under
5
A relatively simply program that reads the temperature from an attached sensor and displays the
temperature in degrees Celsius takes up 1.5K words
18
3.2. Design
4K words. In practice, this was not possible and a newer target of 5K words was
set.
When a user program is running, the bootloader should not monopolise the processor. In other words, it should not take control of the processor too often, or for
too long a time such that it would delay the user program too much. Quantifying
this is very difficult and an attempt would simply be made to minimise this.
Variables
There are a number of parameters in the bootloader which may vary between situations. Thus, rather than hard coding these parameters into the bootloader, they will
be stored in a separate memory area which can easily be altered by a user program
should an update or change be required. The external EEPROM on the Internet Engine
board provides 32K words of data space. The last 512 bytes are reserved for use by
the bootloader and should not be used by any user program. The variables that will be
stored in this area are listed below. Appendix C.2 provides a memory map showing how
and where each variable is stored in memory.
AT commands - The commands required from the host device in order to initiate a
PPP connection (and and an Internet connection with the provider). For example,
a GPRS telephone requires, at the very least, the GPRS initialisation command,
ATD*99#.
IP address - The IP address of the back end that the device must connect to. Although
a computer name would be preferable to an IP address in order to cope with IP
address reallocations or the computer being moved to a new network, this would
require domain name resolution code in the bootloader, which, given the space
limitation would be inappropriate.
Port - The port on the back end that the device will connect to for the control channel.
Name - Every SCADA Engine has a unique name with which it can identify itself to
the server. Any plain text string can be used.
Username & password - Depending on the GPRS provider, a username and password may be required for the PPP connection (and consequently the Internet
connection) if the password authentication protocol is used. Telstra, for example,
requires the username and password to both be blank, while Optus requires the
username to be set as the phone number of the connecting telephone.
19
3.2. Design
Operation
The key to the operation of the bootloader is in its interrupt handlers. As briefly
mentioned in section 3.1.1, the Seiko TCP/IP hardware stack raises the voltage on one
of its pins on specified TCP events. These events are configured by writing specific
values to the relevant registers on the S7600A. The events that are of consequence to
the bootloader are the TCP data arrive and TCP disconnect events. By having the
S7600A raise the voltage on pin 3 - which is connected to pin 4 on port B on the
PIC (see schematics in Appendix D.1) - when one of these events occur, allows the
microprocessor to be notified. Since the PIC can be configured to generate an interrupt
on any voltage change in one of pins 4-7 of port B, we immediately have a method of
handing control to the bootloader on any occurrence of one of the desired TCP event.
Even after a program has been downloaded and is running on the microprocessor,
whenever the S7600A receives data over the Internet, or detects that the peer is trying
to disconnect, the interrupt service routine is called. This causes the currently running program to halt execution and control is essentially given back to the bootloader,
allowing it to upload a new program, or deal with a peer disconnection as appropriate.
Once a program is up and running on the Internet Engine, the downloading of new
programs is likely to be very infrequent. It is also hoped that any disconnections will
be infrequent, and hence this interrupt routine will not be called very often, leading to
a minimal amount of disruption to the running user program.
Since a TCP channel is packet switched, something could go wrong in the underlying
network thus leading to no route between two nodes. Neither node will know of this
until they try to send something to their peer. However, since the interrupt routine is
triggered by a TCP event, there is nothing to notify the bootloader of a lack of TCP
events. For example, if the underlying network goes down the interrupt routine will
never be called because the server will not be able to contact it. As far as the SCADA
Engine is concerned, this is no different from the TCP channel working, but not being
contacted by the server.
In order to solve this problem, a timer on the PIC is used in order to regularly ping
the server. The timer generates an interrupt which is handled by a specific interrupt
handler. So long as the user program does not disable the timer, the bootloader will
generate the heartbeat ping on a regular basis, even when a user program is running.
The interrupt handler needs to send a ping to the server and then wait for a response
(this is the only way to ensure that a full duplex connection still exists). If a response
is not received within a reasonable amount of time, the bootloader assumes the TCP
connection is down and tries to re-establish it. Reasonable can mean anything from a
few seconds to a minute. However, as long as the bootloader is waiting for a response,
the users program will be paused, and hence this amount of time should be minimised,
while still allowing for the round trip time of a TCP packet. GPRS has a minimum round
20
3.2. Design
trip time of 2 seconds and a further few seconds is needed to allow for a potential round
trip across the globe. A value of between 10 and 30 seconds is deemed reasonable.
3.2.2
Back End
The back end server, as mentioned in 3.1.4, is an application which maintains a

persistent connection with all of the devices, this is the job of the back end. The back
end is a Java application that manages these connections. It is the only part of the server
that communicates with the SCADA Engines (as shown in figure 3.2). The persistent
state with the devices is contrasted with the connection between the front end and the
back end.
Although users do not interact directly with the back end - rather, they do so by
interacting with the front end - section 3.2.5 describes a straightforward plain text and
XML based communication protocol between the front end and the back end. The choice
of this protocol was such that at some time in the future, it could be possible to provide
users direct access to the back end.
Functional Requirements
Wait for new devices that come online and initiate a connection with it.
Maintain a connection with each and every SCADA Engine, such that when the
need arises to send data to them, the channels are available.
Listen for incoming messages from devices and feed them into a messaging system.
The latter currently involves simply putting all incoming messages into a database.
Provide feedback data to the front end (for example, advice of a successful program
upload).
Relay requests from the front end (for example, sending a message to a SCADA
Engine, or uploading a new program).
3.2.3
Front End
The web front end consists of a collection of PHP scripts and provides the user
interface for the system. Users need only a standard web browser and an Internet
connection in order to manipulate the system. Since the front end is based around
HTTP, it can also be accessed programmatically should the user desire to do so.
Although all user initiated control of the devices is done via the front end, the front
end is not able to communicate directly with the devices as it is simply a collection of
stateless web pages. This, as detailed in section 3.2.2 is the job of the back end. The
21
3.2. Design
front end, upon receiving input from the user, instructs the back end to communicate
with devices using the communication protocol defined in section 3.2.5. Via a direct
link to the database, the front end also provides access to messages sent back by user
programs on running on the SCADA Engines.
Functional Requirements
Help users write code - This information should be accessible via a Help! link on
the web pages. Although the user will have to obey the coding guidelines associated
with the microprocessor and the given compiler, there will be additional guidelines
specific to the SCADA Engine setup. These will include limitations on the code
(such that it is smaller than the size of memory on the chip minus the size of the
bootloader). Other information that needs to be provided to users include how to
send messages using the use send message() function and receive messages using
the message ready() function.
Allow the upload and compilation of source code - The user may upload their
code either by submitting a file to the server, or writing their code in a web form.
The results of the compilation will be shown to the user in their browser. The
source code can be parsed prior to compilation in order to do various checks and
have the necessary header files, scada.h and sysconst.h automatically included.
These header files, which are given in appendix B, perform the following:
sysconst.h - Defines constants used by the bootloader that are useful to user
programs. These constants include the memory locations for incoming and
outgoing messages.
scada.h Tells the compiler to compile code for the PIC16F877, using 14 bit word
instructions.
Contains compiler directives which instruct the compiler to not put code
at the memory locations where the bootloader is located.
Contains compiler directives which prevent the compiler from allocating
to the user program parts of RAM used by resident code in the bootloader
(for example, the system messaging code).
Includes other files which allow the user to use certain constants in their
code (including F877.h which maps names to all of the registers on the
chip).
Specifies the clock frequency of the oscillator on the Internet Engine
(which runs at 7.3728MHz).
22
3.2. Design
Provides the interface to the send message() function such that the user
simply has to call this function in order to access the message sending
capabilities of the bootloader.
The preprocessing operations performed on the user code include:
Ensuring the user program does not use any interrupts or the low power sleep
mode.
Inserting compiler directives around the user implemented message ready()
function it is relegated to a known location in memory (if the user has not
implemented this function, an empty message ready() function is created).
Following the compilation, some post processing occurs as well. The listing and
error files generated by the compiler provide some useful information and can be
used to screen programs. Most importantly, the compiler listing file can be parsed
to ensure that the user program has not used more than 3 levels of the stack (the
reasoning for this is discussed in section 6.3.2).
Provide a method to upload programs to a SCADA Engine - This would be achieved
by the front end connecting to the back end and passing it the program as well as
the device to upload it to. When the back end receives an upload response from
the device, it passes it to the front end. The result, or any errors are displayed in
the web browser for the user.
Allow the sending of messages to SCADA Engines - The user would needs to
choose a device and enter a message (and have a program on the device that
will react to the message as desired). The message is passed to the back end along
with the destination device. The back end sends the message to the device and
reports to the front end whether it was received by the SCADA Engine or not.
Display messages sent from a SCADA Engine - Messages arriving from the device are stored in the database by the back end, the front end simply provides a
easy way to access these messages.
3.2.4
Database
A Microsoft SQLServer database is used to store all incoming messages from SCADA
Engines. When the back end receives a message from a device, the message needs to
either be stored so it can be retrieved by the user at a later date, or forwarded straight to
the user via some messaging system. This project was concerned with the device itself,
and not the messaging system. Adding all incoming messages to the database provided a
23
3.2. Design
very simple, yet elegant solution. Although SQLServer was used, any relational database
could provide the same functionality.
The table used to hold the messages is defined in Table 3.1
Field
msgid
Definition
Description
unique integer The primary key identifying the message.
not null
device
varchar(128)
The name of the device.
messagefromdevice varchar(1024)
The contents of the message.
date submitted
date
Date and time of message submission.
Table 3.1: Format of Database Table Used to Log Messages
Incoming messages are inserted into the database via an ASP script that can be
called from the back end. Messages can be retrieved from the database via a link on a
front end page which uses another ASP script that allows direct SQL queries.
3.2.5
Inter-module Communications
As one can see in Figure 3.3, there are essentially two places where there is internal
interaction between the modules of the system; between the front end and the back
end, and between the back end and each device. There are also two points of external
interaction; these are between the user and the front end, and between the device and
any peripherals that may be attached.
Back End SCADA Engine
There are two interfaces between each SCADA Engine and its controller, the data
channel and the control channel. Both channels are TCP connections established by the
device with the back end.
Control Channel - The back end will listen on a pre-determined and pre-configured
port that is known to all the devices. The main purpose of the control channel is
for the uploading of new programs to the device, as well as ping signals. The communication follows the sequence described in Appendix A.1 where each message is
a single line and is terminated with a line-feed. Upon initial connection with the
back end, the SCADA Engine transmits its unique name and receives an integer
response from the controller. This integer is the port number which to connect to
the server on for the data channel.
Further communication on this channel only occurs for one of two reasons:
1. To download a new program - If the first character of the string received
from the back end is a D, then this indicates that a program download has
24
3.2. Design
Back End
Front End
The controller is the point

of contact between the
Internet Engine and the
user (via the front end)
TCP Communication channel

(arrow indicates primary
direction of information
flow)
Indicates relationship of
one thread (top) spawning
many threads (bottom)
Front end
listenner
Device
listenner
Controller
One controller per device.

Data Channel This TCP pipe
is available to the user for
sending control data, and
receiving data acquired from
the device.
This TCP
channel will be used to:
1. Notify the back end
of a new file to upload.
2. Relay data for the data
channel between the user
and his/her program on
the Internet Engine.
3. Query the front end
listenner for information
on available devices.
Control Channel New programs

are sent to the Internet
Engine through this channel.
The GUI is a web based

interface. This is the
only point of access for
the user.
Internet Engine
User program
Bootloader
Figure 3.3: Logical Interaction Between the Modules

been initiated. The back end then sends the HEX file6 contents as defined in
Table A.2 in Appendix A.1.
2. For pinging - As discussed in section 3.1.4 there is a need for each side to ping
the other side. Any string sent from the back end which is not a download
request (or download contents as determined previously) is considered to be a
ping. The device responds by echoing the first character back to the back end
(this is done for ease of implementation). Similarly, if the SCADA Engine
pings the back end by sending a string, it gets echoed back.
Data Channel - The SCADA Engine connects to the back end on the port specified
during the initial conversation on the control channel (see above). This is the data
channel.
Messages are sent back and forth through the data channel at the bequest of the
user or the users program. A message is defined as a sequence7 of ASCII characters
terminated by a line-feed (\n) character. The choice of the newline character being
6
The HEX file is output from the CCSC compiler and is a convenient way of representing the program
image. In addition to the binary code of the program - it contains checksums and is written in printable
ASCII rather than pure binary.
7
The implementation method requires some limit on message sizes. An arbitrary length of 2KB
(including the termination character) was thought to be more than sufficient.
25
3.2. Design
the termination character is to allow easy testing and demonstration as it can be

replicated easily when substituting the SCADA Engine with a terminal program.
However, in production, a less commonly used ASCII character (such as the null
character) could be used. The newline itself does not form part of the message.
The protocol for sending a message consists of the node that wants to send the
message, simply sending the message. The peer then responds with a line-feed
terminated line (a single character line consisting of a line-feed is even sufficient) to
acknowledge receipt of the message. This ensures that the sending node knows does
not assume that passing the message to the underlying TCP/IP stack guarantees
delivery, as delivery is only guaranteed if the peer is still contactable.
Front End Back End
The front end listener is a module in the back end dedicated to communicating
with the front end. It uses a server socket which waits for connections - the front end is
always the initiator of a conversation. The communication protocol is based on plain,
line based ASCII. Any of the following requests can be made by the front end via this
channel:
Find out which devices the back end is currently in contact with.
Uploaded a user program to a specific SCADA Engine.
Find out the status of a specific device (ie., whether it is online, whether the last
program upload was successful, etc.).
Send a message to a specific device.
A complete definition of the communication protocol is provided in Appendix A.2.
There is no specific quit command as the connection only lasts as long as the command
itself. There is scope however to extend the command set to use persistent sockets which
will avoid the overhead of creating a new connection each time the front end needs to
communicate with the back end. For a small number of users however, the overhead
associated with socket creation is not an issue.
3.2.6
External Interfaces
There is interaction between the user and the web based front end as well as some
interaction between the SCADA Engine and any peripherals that may be attached to
it.
The users interaction with the front end may either be via a web browser, or through
HTTP requests made programmatically in custom built user applications.
26
3.2. Design
Any interaction between the Internet Engine and attached peripherals will be fully
dependent on the particular peripherals attached. Many peripherals will use basic digital
or analogue IO which can easily be handled by the Internet Engine. Similarly, RS-232
communication can be used (with help from the compilers RS-232 library) together
with the available DB-9 serial port. More complicated communications protocols would
need to be implemented manually by the user.
3.2.7
Software Interfaces
A user program may interact with the bootloader either directly (by calling a function), or indirectly (by having a call-back function made available to the bootloader).
This is the means by which messages can be sent and received.
Sending Messages
As detailed in section 3.2.4, all messages sent to the server get inserted into the
database, with the date and time recorded, along with the name of the device that the
message originated from.
A message can be sent by placing the text to be sent in the external EEPROM beginning at location 0 and terminated with a line-feed. A call to the function send message()
must then be made to actually send the message. The constants SEND MESSAGE LOCATION
and SEND MESSAGE LOCATION MAX define the locations in memory where a message to be
sent should be placed.
Functions for writing to and reading from external EEPROM available in the header
file 24lc256.h (see appendix B).
The code snippet below would send the message Hi to the server.
write_ext_eeprom(SEND_MESSAGE_LOCATION, H);
write_ext_eeprom(SEND_MESSAGE_LOCATION+1, i);
write_ext_eeprom(SEND_MESSAGE_LOCATION+2, MESSAGE_TERMINATION_CHAR);
_send_message();
Receiving Messages
Messages can be sent to a user program via the front end Monitor web page. When
the a message arrives at the device, the bootloader will take control, read the message
and store it in external EEPROM. It then calls the user implemented message ready()
function. This is done by the bootloader having a command hard-coded to call a specific
address. By default, the address simply contains a return instruction (and thus sending
the message has no effect). When a user uploads source code to be compiled, the front
end ensures that the users message ready() function (if there is one) is put at the
27
3.2. Design
known address in memory (by the process described in section 3.2.3). Thus, if the user
has implemented this function, it is called straight after a message is received by the
bootloader.
The message is stored starting at the address 2048 (RECV MESSAGE LOCATION) and
terminated by a line-feed.
Once the user program returns from the message ready() function, the bootloader
returns from the interrupt handler and then control returns to the user program at the
point of execution where the interrupt for the arriving message occurred in the first
place. If a new message arrives it will overwrite the old one. Thus, if the user program
requires that a message persists, it should be stored elsewhere. Similarly, a new message
will not arrive until the code returns from the users message ready() function.
An implementation of the message ready() function for a program that is waiting
for a message with the letter x in it before something happens, is given below.
static int take_note = 0;
void message_ready() {
char ch;
int len;
ch = read_ext_eeprom(RECV_MESSAGE_LOCATION);
while (ch!=MESSAGE_TERMINATION_CHAR) {
if (ch==x) take_note = 1;
ch = read_ext_eeprom_next_byte();
}
}
28
CHAPTER 4
Implementation
4.1
Equipment
The following equipment is required in order to reproduce this project.

Internet Engine development board. This board can either be purchased preassembled or built using off the shelf components[6] as detailed in appendix D.1.
The key components are the PIC16F877 microprocessor and the Seiko S7600A
hardware TCP/IP stack.
PIC programmer and cables. The Dontronics programmer can be used together
with the wiring to the Internet Engineas described in section 3.1.1. A parallel
DB-25 printer cable can be used to connect the computer to the programmer.
GPRS capable mobile phone or modem and an account with a GPRS service
provider. The Motorola Timeport P7389i and a Telstra account were used for this
project, however, theoretically any other provider and GPRS capable GSM phone
or modem should work (subject to the discussion in section 6.1.2).
A personal computer. The PC must be connected to the Internet and have a globally accessible IP address1 . Table 4.1 indicates the software required to complete
this project, as well as the software required on the PC when it is used as a server
after the project is completed. Details of the computer setup during development
is given in section 4.1.1. Although specifications are given for a Microsoft Windows
PC (Windows 2000 was used for the project), another operating system could just
as easily be used, for example, Linux (with corresponding Linux software).
1
A globally accessible IP address is a non private one, as specified in RFC1918[22]
29
CHAPTER 4. Implementation
Application Required
for...
Web server
production
PHP 4.1.2
production
Java
compiler
Java
runtime
C cross
compiler
development
PIC
programmer
development
Terminal
application
development
CVS client
development
production
production
4.1. Equipment
Notes
The web server used is Microsoft Internet Information Server (IIS) 4.0). The web server needs to be
capable of running CGI scripts.
The front end is written in PHP. A Windows PHP
binary that automatically configures IIS is available
free of charge.
The Java Development Kit (JDK) 1.3 is required to
compile the back end source code.
The Java Runtime Environment (JRE) 1.3 is required to run the back end.
The cross compiler provides one with a method to
write and compile source code on a PC for the PIC
chip. It is used for compiling the bootloader as well
as user code submitted by via the front end.
Many PIC programmer applications exist, but
PicProg877[10] was found to be the most intuitive.
It gives one the ability to program compiled code
into the microprocessor using the PIC programming
board.
Any terminal program capable of interfacing with
a COM port can be used. Windows Hyperterminal
(bundled with Microsoft Windows) or Tera Term[28]
are two examples.
Tortoise CVS[11] was used. Any CVS client can be
used, and is only required if retrieving the source
code from a central repository.
Table 4.1: Development and Production Software Required.
4.1.1
Development Computer
The software required on the PC during development is listed in Table 4.1. All of
the software marked as production should also be installed on the computer in order
to conduct testing. A relatively basic PC can run all of the software - any Pentium
(or equivalent) processor and above is good enough. The PC needs to have at least
one spare COM (RS-232) port. The COM port is connected to the female DB-9 port
on the Internet Engine and can be used together with a terminal program to display
output from the microprocessor. The PIC can be configured in software to use RS-232 at
many different speeds, however 2400bps with hardware flow control enabled is sufficient.
When C printf() and putchar() statements are executed on the PIC, the output is
displayed on the PC. Without this, debugging is extremely difficult.
30
4.2. Method
Making Development Cheaper and Simpler

While building and testing the system, it may be easier (and less costly) to use a
computer to provide the Internet connection to the Internet Engine rather than the
GPRS handset. The computer may be the same computer as the development PC and
acts as a PPP server2 in the same manner that the GPRS handset does. A computer
running Windows 2000, connected to the male DB-9 port on the Internet Engine using
a null modem cable to a spare COM port, can easily be set up to do this through
Network and Dialup Connections. Simply add a connection using the Connect directly
to another computer option and choose to act as the Host. The connection should
be set up to run at the same speed as the handset (the Timeport runs at 57600 bps)
and using hardware flow control. On the SCADA Engine side, the PPP initialisation
commands in the external EEPROM need to be changed to the commands required by
Windows (as opposed to those required by the handset). The TCP/IP settings then
need to be modified to ensure IP addresses are allocated as expected.
4.2
Method
In order to create each of the three sub-systems, the SCADA Engine, back end and
front end, the following steps need to be taken. All the source code can be retrieved
from a CVS3 server, siscvs.act.cmis.csiro.au with an appropriate username and
password. Alternatively, the complete source code can be found on the accompanying
CD.
The coding for each of the three sub-systems is better done incrementally, especially
with regards to the bootloader. An approach that will simplify the development process
is to try get each sub-system working as well as possible prior to beginning work on the
next component.
4.2.1
Back End
The back end follows the standard model of a thread based TCP server and can
be developed independently of the other two subsystems. All that is required is the
Java Development Kit (version 1.3 or above). Since the devices connect to the back end
using a raw socket and communicate using plain ASCII, this can be simulated by using
a telnet client to connect to the back end on the required port and using it to act as
the SCADA Engine. In a similar manner, the front end communicates with the back
end using a raw socket and plain ASCII.
2
Technically speaking, a PPP server is no different from a PPP client. Here the word server is used
to indicate the side of the connection providing the service[19].
3
Concurrent Versions System - this is a method of version and source code revision control.
31
4.2.2
4.2. Method
Front End
One part of the front end consists of a series of web pages which provide an interface
for users. Creating these pages is of minor concern. The sophistication of the front
end lies in the dynamic nature of the pages, and their interaction with the back end.
PHP was chosen as the scripting language due to the authors familiarity with it, its
flexibility, as well as its comprehensive collection of socket related functions.
Much of the functionality of the front end relies on communication between it and the
back end. During the development of the front end, rather than having it communicate
with the as yet not fully tested back end, one should create a very simple TCP server
application which simply allows the front end to connect to it, and outputs to the screen
any data that the front end sends to it through the socket. This provides a relatively
straight forward means of debugging the front end independently of any bugs that may
exist in the back end. Once the front end is working in an acceptable manner, the TCP
test server should be replaced with the back end.
Integrating the front end and the back end will require the removal of any discrepancies that may exist in the protocol implementation by the two modules, as well as other
potential bugs. This integration testing can be completed by having the front end and
back end work together, but still using a telnet client to connect to the back end as if it
is a SCADA Engine.
4.2.3
SCADA Engine
Writing the bootloader code is the most difficult part of the development process.
The reason for this is that it is especially hard to debug code running on the PIC as
there is no debugger which can be run on top of the running code. All debugging takes
the form of including output statements at various points in the code (either in the form
of changing the voltage on one of the pins, or actually printing text to a PC terminal
screen using the RS-232 capabilities of the chip).
As discussed in section 3.2.1, some parameters used by the bootloader are stored
in memory rather than being hard-coded. These parameters are stored in the reserved
area of the external EEPROM as shown in Appendix C.2. A simple program such as
put prom (included on the accompanying CD, Appendix B), the data in the external
memory can be easily changed. This can be done either prior to writing the bootloader,
or right at the end, after building the bootloader using hard coded parameters.
By getting parts of the bootloader to work in an incremental fashion, a lot of heart
ache can be saved.
1. Very basic TCP functionality should be implemented. Using the same TCP server
tester program that was used in the development of the front end, a basic TCP
32
4.2. Method
client can be created on the PIC that initiates a PPP session with the GPRS
module, and then makes a TCP connection to the server.
2. Implement bootloader code which takes data (the HEX file which is output by the
compiler), parses it appropriately, and writes it into program memory (without
writing over itself of course).
3. The bootloader code can then be combined with the TCP code such that after
initiating a TCP connection, if data is sent back through the channel (once again,
the TCP tester program can be engineered to do this), that data is treated as a
HEX file and loaded into program memory.
4. The interrupts now need to be implemented. After some very basic interrupt
testing is done, the PIC needs to be set up such that it receives interrupts from
the S7600A TCP stack. This is done by configuring the S7600A to cause an
interrupt on certain TCP events. These interrupts trigger a voltage change on one
of the S7600A pins. This pin is connected to port B of the PIC which is set up
as an input, and is configured to trigger an interrupt whenever the voltage on it
changes. TCP interrupts can now be tested and linked into the existing bootloader
code, such that after the bootloader loads a program, the arrival of data on the
TCP channel will trigger an interrupt and cause a re-entry into the bootloader
code.
5. Setting up of a second TCP channel with the back end - the messaging channel
- needs to be implemented. One important issue to take note of here is the way
multiple sockets are implemented on the S7600. Two sockets are available for use
on the chip, and each socket operates independently of the other. By writing to
a specific register to select which socket to use, all other socket and TCP related
registers are effectively offset to the chosen socket. Thus if the first socket is
selected for use, and a connection is established with a host, and then the second
socket is selected, all settings need to be explicitly written to the S7600A for the
second socket. They are totally independent of the first sockets settings, including
all interrupt related options.
6. Once both TCP channels are actively maintained, the TCP tester program should
be replaced with the back end, and the two components should undergo integration.
Various other issues need to be dealt with, these include:
Sending a message from the SCADA Engine to the back end. After this is
done, a send message system call needs to be written in the bootloader, and
access provided to it for downloaded programs.
33
4.2. Method
Receiving a message from the SCADA Engine to the back end. Once this is
working, a method of notifying a user program by means of calling a predefined function in user code needs to be implemented. This can be done by
means of calling a memory address that is hard coded into the bootloader.
Robustness needs to be built into the system by having the bootloader ping
the back end at regular intervals to make sure the connection is still up. This
can be implemented by using one of the timers on the PIC which can be
configured to trigger an interrupt which once again, hands control back to
the bootloader. It should also be able to respond to such keep-alive pings
from the back end. The SCADA Engine also needs to be able to recover from
problems such as the following:
If the TCP channel is found to no longer be up, the bootloader must try
to reconnect to the back end. If it fails to reconnect it tries to disconnect
from the Internet and then try again.
If someone attempts to download a program (either accidently or with
malicious intent) to the device that that is compiled to reside in areas
of memory occupied by the bootloader4 , it must not write those parts of
memory and report to the back end that the download failed.
Given the non-trivial nature of the coding, it is best done by achieving full functionality prior to reducing the size of the bootloader code to be as small as possible. As
mentioned a few times in this document, only 8K words of program memory is available
on the PIC16F877, and as much space as possible needs to be left for the user program. One should be able to implement the complete functionality of the bootloader as
described here no more than 5K words of memory.
This should not occur during normal operation as the front end tries to prevent this from happening.
However, a fail-safe mechanism is obviously preferable.
34
CHAPTER 5
Results
5.1
Degree of Success
The degree of success of this project can be measured in two ways. Firstly in terms
of whether it achieves the basic goals set out in section 1.3, and secondly whether it can
be used in a real life situation.
A working system was created and all of the design requirements were fulfilled. By
the first measure of success, the system is successful. However, this in itself does not
mean that the system is potentially useful. If the implementation is such that it is very
clunky, for example, the bootloader still takes much of the CPU time even when another
program is running, then the system is will not be usable in any practical situation. The
device created however, together with the back end and front end software does provide
a very usable system. Not only do all parts of the system work as desired, but real life
SCADA applications can be developed on the SCADA Engine.
Developing a SCADA application for the SCADA Engine involves coding the necessary program and submitting it to the front end for compilation, and eventually uploading it to a device. Obviously, the device needs to be turned on and have any required
sensors1 attached to it via raw IO pins, or through the serial port that is available on
the board. Section 5.2 shows how a simple remote temperature sensing application can
be created for the SCADA Engine.
5.2
Sample Program
In this section a sample user program that demonstrates the full capabilities of the
SCADA Engine is shown in detail. The program, tempdemo turns the SCADA Engine
1
The sensors required are determined by the particular application.
35
CHAPTER 5. Results
5.2. Sample Program
into a remote temperature measuring device which will report back to the server the
current temperature on demand.
Given that the Internet Engine board comes with a Dallas Semiconductor DS1629
chip which has a built in temperature sensor, so there is no need to attach an external
temperature sensor to the device. The DS1629 uses the I 2 C protocol2 to communicate.
The demonstration application, once loaded, flashes an LED which should be connected between pin E0 (this pin is brought to the edge of the board) and ground. This
is done simply to provide user feedback to verify that the program is running.
The code implements the message ready() function such that when a message is
sent to the device, it parses the message. If the first character of the message is a capital
K, then a flag is set. The main part of the program that flashes the LED polls for the
flag. If the flag is set, it queries the DS1629 for the temperature, and then sends a the
current temperature, as a string, to the server using the system call send message().
The flag is then reset and the LED flashing continues.
Clicking on the retrieve messages link on the Monitor page on the front end shows
all of the messages sent by tempdemo. The messages are retrieved directly from the
database and presented in XML format. Here one can see that the unique name of
the device running the program was Einstein, and it obviously received two messages
beginning with the letter K. The temperatures at the given times are in degrees Celsius.
<?xml version="1.0" encoding="utf-8" ?>
<Results>
<MessageFromDevice msgID="257" Device="Einstein"
MessageFromDevice="15.0" Date_Submitted="2002-06-18T14:10:40" />
<MessageFromDevice msgID="256" Device="Einstein"
MessageFromDevice="18.5" Date_Submitted="2002-06-18T13:56:16" />
</Results>
The source code for the application, called tempdemo can be found on the CD accompanying the thesis (see appendix B).
The tempdemo application demonstrates both the message sending and receiving
capabilities of the system. It shows how messages can be used to control the device,
and how the device can report data back to the server. The LED flashing serves two
purposes, firstly so one can see that the program is running, and secondly to demonstrate
how easy it is to control an external peripheral using raw pin IO (although in this case
the peripheral is very basic).
2 2
I C is a straightforward 2-wire protocol, the details of which are unimportant as the CCSC compiler
provides an easy to use programming library for I 2 C functions.
36
CHAPTER 6
Discussion
6.1
6.1.1
Development and Implementation Choices

Server Model
Theoretically, a system could be developed without a server in the model. In such

a model users would communicate directly with their devices as shown in Figure 6.1.
However, due to complexities involved in such an implementation, this method was not
chosen. The foremost complicating factor is that as detailed in section 3.1.4 there are
many limitations imposed on devices connecting to the Internet via GPRS on Telstras
network1 - the relevant one being that a connection cannot be initiated from a node on
the Internet to a GPRS device due to the limitations imposed on a private IP address as
detailed in RFC1918[22]. Hence, the devices cannot be set up to accept TCP connections
directly from the user. This means that the SCADA Engines themselves would have
to be the initiators of any connections, meaning that they would have to poll the users
directly for control signals.
The server model also provides the benefits of a single point of contact, as described
below.
Single Point of Contact
Consequently, a more appropriate model is to have a server that acts as a common
point of contact for both users, and SCADA Engines. This model is depicted in Figure
3.2 and is the one adopted for this project. By giving all of the devices and all of the
users a single point of contact, the potential points of failure are moved from the devices
to the server. Dealing with problems on one server is a lot easier than dealing with a
1
Telstra is used as a benchmark as they provide the largest GSM network in Australia.
37
CHAPTER 6. Discussion
6.1. Development and Implementation Choices
Figure 6.1: Module Interaction for a no server Model

problem on all the SCADA Engines which may be spread out all over the country. It
also means that configuring the devices is a lot simpler as more logic can be programmed
into the server which is a lot easier to program and debug than a SCADA Engine, and
also leaves the devices free to perform their primary task - control and data acquisition.
Continuous Connection
A further consequence of the GPRS limitation is that when the server needs to send
data to the SCADA Engine (for example, to upload a new program to it, or send a
message) is that a constant communication channel needs to be maintained between the
server and all of the devices. Normally, if the device was given a public IP address, one
would reasonably assume that the communication should be initiated from the server to
the SCADA Engine. Since this is not possible, a communication channel is constantly
maintained, such that when the server does need to send data to the device, there is no
longer an obstacle of establishing a connection with a device behind a NAT.
The connection is established in the first place by the SCADA Engine immediately
after booting, and it is the responsibility of the device to re-establish the connection if it
is lost for any reason. However, since a TCP channel is connectionless (as it is a packet
switched connection), there is no intrinsic property giving the state of the connection.
Thus, if and when the communication channel drops out (for example, because the
network cable was severed), neither node would know of this until it tries to use the
connection by sending or receiving data. Consequently, both the server and all devices
must send small packets at regular intervals to check if the peer is still contactable.
These heart-beat packets are known as pings.
Since traffic between the Internet Engines and the back end needs to be kept to a
minimum due to cost considerations, the ping packets should be minimal in size, and be
38
sent as infrequently as possible. A discussion of the optimal frequency of sending pings

can be found in section 6.1.5. If a SCADA Engine fails to send a ping packet (or does
not receive a response from a ping packet) it makes an attempt is made to re-establish
the connection.
6.1.2
Connectivity for the SCADA Engine
Choice of GPRS Modules

The Motorola Timeport P7389i, although a prototype GPRS consumer handset, was
found to operate perfectly well. The other handset2 tested was the Ericsson T39m,
however it behaved differently over the serial connection to the Timeport and always
disconnected from the Internet immediately after connecting when driven by the Internet
Engine. Consequently the T39m could not be used for any SCADA Engine GPRS related
testing. As GPRS usage becomes more widespread, one would expect the convergence
of operation modes and a greater ability to interchange between handsets as well as
commercially available GSM/GPRS modems.
Choice of Providers
GPRS is a relatively new technology. In Australia, Telstra was the first telecommunications company to offer the service. The first trials started around the middle
of 2001. Optus, Australias second largest telecommunications company only began
offering GPRS at the end of 2001.
Telstra was used as the provider throughout this project for a simple reason. The
mobile telephone used, the Motorola Timeport was SIM-locked to Telstra meaning that
a SIM card from another provider would not work in it. An unsuccessful attempt was
made by Telstra to remove the lock.
Just like the system should work with other standard GPRS telephones or modems,
it should work with other GPRS providers. But given that GPRS is still a relatively
young technology, this may not always be the case.
6.1.3
Compiler Software
The CCSC compiler[2] was chosen purely because of its price (about a quarter the
price of the more highly regarded, Hi-Tech C compiler3 ). In the course of 4 months of
programming with it, three bugs were found:
2
Between the time the project was started in November 2001, until it was completed in June 2002,
the number of GPRS handsets on the market in Australia rose from one, to approximately 10. However,
due to time and money constraints, only two handsets were tested.
3
See http://www.htsoft.com for further details.
39
Contrary to the specification in the compiler manual, interrupts could be enabled

without calling enable interrupts().
The compiler directive #separate, used to prevent the compiler from inlining a
function, had no effect.
Nested function calls with 16 or 32 bit parameters only receive the bottom 8 bits
of return values from inner functions.
Work arounds for all of the bugs were eventually discovered and implemented, but
the fact that the compiler acted differently to what was documented, made finding
bugs a lot more time consuming than was necessary. In addition, according to some
PIC programmers the compiler is known to not optimise code as well as the Hi-Tech
compiler4 . Further development (particularly if commercialised) may require use of a
better compiler.
6.1.4
User Program Storage
Although the choice was made to have the user program and the bootloader share
the program memory on the PIC (and hence limit the user program to approximately
3K words), another option is available. The user program could be downloaded and
stored in the external EEPROM, and a fetch, decode and execute model could be used
to run the program. This would only require a small amount of program memory to be
available for parts of the user program to be paged in as needed and would operate in a
very similar manner to a page-file5 on a modern operating system. Running programs
that are larger than the amount of available RAM are stored in a page-file on disk, and
then parts are paged (loaded) into memory as they are used. This would then allow
the user program to be much larger and would only be limited by the size of EEPROM
chips one would be willing to purchase and connect to the PIC.
The reason this was not done is due to the complications involved. Programming
a memory paging system can be quite complex and the time this would have required
would be disproportionate the total available time for the project. Additionally, 3K is
deemed sufficient space for many SCADA applications, particularly for a first generation
system. Future systems may be developed using microprocessors which have more internal memory. Another factor is that having operating system paging makes real time
processing and timing by the user program a lot harder and almost impossible without
specific functionality provided by the operating system (or bootloader).
4
This information was gathered in the form of anecdotes on various PIC related message boards on
the web.
5
Also referred to as a swap-file.
40
6.1.5
Cost Versus Robustness
The running cost of a SCADA Engine is primarily determined by the GPRS communication costs. As of June 2002, Telstra6 charges 2c per KB of data transfered over
GPRS7 . The connection fee, which is 20c for Telstra, is in addition to the data transfer
fee. Theoretically a connection can be maintained indefinitely, since GPRS is advertised
as the always online solution. However, in reality, the connection drops out some times
and needs to be re-established.
At this point it is important to note how a kilobyte is defined. According to the
Telstra mobile services help-desk, charges are on all bytes coming into or going out of
the handset. This means that the charge is not on the payload, but on the data including
the IP and TCP headers that make up the TCP packets. To put this in perspective, the
largest packet the S7600 chip can send out is 1KB[25], including TCP and IP headers
which require a minimum 20 bytes each[20][21] (more if certain TCP or IP options are
set), thus giving a maximum useful data transfer of 96%. In reality, packets smaller
than 1KB are often transmitted, especially when dealing with the Internet Engine.
Downloading Programs
Given that programs are not likely to be uploaded to devices very often (once a
device has a program loaded on it, it should not need to be replaced in the immediate
future), the cost of uploading programs is minimal. Even for a 3K word program (which,
together with the bootloader would take up the whole of program memory), the cost
would be less than 50c (although the program is only 3K words, the HEX file which the
compiler outputs is a lot larger as it contains other information such as checksums, line
breaks, start characters, and so on).
Messaging
The cost associated with messaging is also limited. As an example, for a device
that monitors weather parameters - for example, temperature, humidity and barometric
pressure - and sends the data back to the server every minute, the cost can easily be
worked out. Each of the 3 parameters could be stored as a 64 bit floating point number.
Thus, every minute, 3 64 bit numbers (24 bytes in total) would have to be sent to the
server. Sending 24 bytes of data, plus the minimum 40 bytes in TCP/IP headers per
minute would land up costing 0.0859c per minute, or $1.24 per day!
6
Although not the only Australian carrier offering GPRS, given the lack of mobile carrier competition
in Australia, Telstra can be considered a good benchmark for costs.
7
This does not include 10% GST, and does not take into account a 50% discount applied once the
first 500KB have been transfered in a single session.
41
6.2. Communication Protocols
Pinging
The communication cost begins to become significant when pinging is introduced.
As detailed in section 3.2.5, devices need to ping the back end, and the back end needs
to ping the SCADA Engines. The back end needs to ping the SCADA Engines to ensure
it does not give false status reports to the front end about one of the devices. Similarly,
the devices need to ping the server to ensure that if a connection does drop out, it will
be re-established, in case it needs to be contacted by the back end. All successful pings
consist of a short message (the ping), and the node receiving the ping responding with
an acknowledgement (an echo of the ping). It becomes apparent that there is a trade
off between the frequency of pinging, and the reliability and robustness of the system.
Even using a minimal ping packet containing 2 data characters (one to indicate the
ping, and the second to act as a line termination character), there is still the minimum
40 bytes of TCP and IP headers, thus giving 42 byte ping packets. Given that each ping
needs to be responded to by the peer, each ping and ping response is 84 bytes, and at a
cost of 2c per KB works out to be 0.164c. Table 6.1 can be drawn up to summarise the
trade off between robustness and cost on a per SCADA Engine basis.
Ping frequency
(device server)
Ping frequency (server device)

1 per minute On request ( 1 per hour)
2 per minute
$7.09
$4.76
2 per hour
$2.44
$0.12
Table 6.1: Cost per 24 Hours per Device Due to Pinging.

The system currently in place is for demonstration purposes and tends towards the
higher cost in order to achieve a high reliability. This is required for demonstration
as a lot of interaction occurs with each device in order to showcase various scenarios.
Each SCADA Engine pings the server every minute, and the server pings each device
whenever a request is made from the front end to find out the status of the device.
6.2
Communication Protocols
6.2.1
Internet Engine Back End
Data Channel
As discussed in section 3.2.5 messages are sent back and forth through the data
channel using a basic protocol: messages are line-feed terminated ASCII character sequences and are acknowledged by a return line-feed terminated sequence (possibly an
empty sequence).
The drawback of this method is that no provisions are made for a case where a
message contains the termination character. In many computer applications, special
42
characters (in other words, a character that has a meaning in the protocol, and is not
just part of the data) can be included as part of the data by escaping them. Escaping
a character means changing the character to a special sequence of characters that will
represent it. In other words, a line-feed could be sent as part of the data by sending the
string \n. However, a special provision needs to be made so the receiver can distinguish
between a \n that is to be interpreted as a line-feed, and a \n that is to be interpreted
as those two characters. This issue can be dealt with, but but requires significantly
more logic in both the sender and receiver more logic. By simply not allowing message
to include the termination character, a lot of logic could be left out of the system. This
was the design choice made in order to keep the code on the PIC to a minimum. It
was felt that the sacrifice was minimal given the small amount of remaining program
memory.
Apart from escaping special characters, two other methods were considered for implementing messages, namely sending the message length followed by the message, and
using XML.
By sending a number prior to each message, the receiving node would know to read
in that number of bytes as the message. This could be implemented by the sender first
sending a 16 bit integer (or any other specific size as appropriate), N , to indicate the
number of bytes of the following message. The peer would know the the next N bytes
make up a single message, irrespective of the characters contained within. Sending the
number encoded as a string requires processing of the string on both ends (encoding
and decoding) and this consists of a fair amount of logic. Sending an integer of a known
length (say, a 16 bit integer) followed by a message requires very little logic to implement,
and consequently this method was in fact implemented first. However, demonstrating
and testing the system is extremely difficult as although computers easily interpret 16
bit integers, humans are not so good at it!
XML messaging is a very attractive option from the point of view of uniformity,
scalability, and ease of use for other developers. XML is a well defined system for storing
data and can be transfered through text based streams (or sockets in this case). Using
XML would mean that no custom protocol would have to be developed, and messages
could be made directly available to users since XML is a commonly used data format.
The problem with XML is the overhead required in creating an XML document, as well
as the higher communication cost due to the superfluous data. The logic required to
create a well formed XML on the Internet Engine would leave very little memory for
other programming tasks! Thus, although an idealistic and attractive option, XML,
currently, does not fit well with such small microprocessor architectures.
43
Control Channel
Similar to the options for communications protocols in the data channel, there were a
variety of possible implementations of a communications protocol in the control channel.
The protocol used, as defined in section 3.2.5, employs a method whereby as little logic
as possible is required in the SCADA Engine. The reason for this choice, again, is in
order to minimise code use by the bootloader, and maximise available space for user
programs.
To illustrate this point, the control channel protocol could have been implemented
fully in XML (and again, this may have been ideal if code space was not a consideration).
Different XML messages could be used for the various conversations between the back
end and the SCADA Engine. For example, an XML document would be sent to the
back end upon connection that would contain identifying information about the device
(including its name). Ping packets and responses could be encoded in XML, and so
could programs to download. Once complete definitions of the XML documents were
defined, the whole protocol would essentially be defined.
The protocol used however, was created specifically for the purpose of the control
channel. Once defined though, implementation was not particularly complicated. For
example, after the initial connection, whenever the SCADA Engine received some data
over the socket, it would examine the first character of the line (terminated with a linefeed). If the character was a D, then the device would go into download mode, and
expect a program download to follow. Otherwise it would simply echo the first character
followed by a newline character to the back end - in other words, respond to a ping from
the back end. In a similar manner, any time the back end received data from the device
(apart from during the initial contact, or as a response to a download), it would assume
it is a ping packet, and echo the data back. As can be seen, it is a straightforward
protocol.
6.2.2
Front End Back End
The method of communication between the front end and the back end is of very
limited concern to this project. The reason for the creation of the front end was to
create an easy way for humans to interact with the SCADA Engines. The ultimate goal
of the project was to create a device would could easily be interacted with, both for
uploading programs, and for messaging. The front end is merely a means to show this,
it is a means to an end and not an end in itself.
Plain ASCII was used such that it would be easy to work with and debug the system.
XML was used in part where it was thought other such front ends may be used to
communicate with the back end some time in the future. For example, submitting a
compiled program to be uploaded to a device is done by transferring an XML document.
44
6.3. Limitations Imposed on User Programs
Rather than a person doing this through the web front end, this may be done by having a
different application send the compiled program directly to the back end to be uploaded.
In general though, a line oriented protocol was used with socket connections lasting
only as long as a single command (and response). Persistent sockets could be implemented in order to reduce the overhead associated with constantly creating and destroying sockets (and related back end threads), but as already mentioned, the primary
concern was to create a system that worked and could demonstrate the concept, but
leaving the door open for further development. This meant that more time could be
spent on the core of the project, the SCADA Engine.
6.3
Limitations Imposed on User Programs
Due to the fact that the bootloader cannot be overwritten by a downloaded user
program, and since some components of the bootloader must still be able to run when
a user program is running (for example, the interrupt routine used to load new programs that arrives over the control channel), certain limitations are imposed on the
user program. Obviously there are some limitations due to the fact that the microprocessor is on a board with other chips (for example, certain pins are used to connect
to other components on the board and cannot be used by user applications). These
limitations[7] are imposed by configuration of the Internet Engine and are unrelated to
the bootloader. The limitations discussed are those which are a result of the SCADA
Engine being different to the bare Internet Engine as purchased.
An attempt has been made to impose some of these limitation by parsing the users
code prior to, and after compilation (as discussed in section 3.2.3). The limitations that
exist, the reason they exist, and how they are dealt with are discussed below.
Note that many of the attempts made to address any problems in the user code are
based around parsing the C code. If the user has bypassed the C code and inserted the
relevant assembler commands, the problems will not be detected.
6.3.1
Memory Usage
The size of the users program limited to 3K words as a result of only having 8K
words of program memory and 5K words being used by the bootloader. By parsing the
post-compilation listing file of the users program, the program size can be determined.
As a failsafe mechanism, the bootloader will not overwrite itself while downloading code,
and thus, will not download code that is too large to fit into the free space in memory.
In addition to the limitation on program memory size, the user program is also
limited in its usage of the external EEPROM in that it cannot use the last 512 bytes
which are reserved for bootloader parameters as described in section 4.2.3. The first 4KB
45
6.3. Limitations Imposed on User Programs
of external EEPROM should not be used either as this area is used by the messaging
subsystem. Additionally, some parts of RAM should not be used as they are used by
the interrupt handlers in the bootloader, and could possibly lead to variables in the
user program being overwritten. The compiler prevents these parts of RAM from being
used when the scada.h (provided on the accompanying CD) file is included in the
compilation. It does does so through the use of the #reserve compiler directives.
6.3.2
Stack
The hardware stack on the PIC16F877 has only 8 words (each function call utilises
one level of it for the return address). The interrupt service routines in the bootloader
use up to 5 levels of the stack, thus leaving only 3 words of stack for the user program.
Consequently if the user program uses 4 levels and then an interrupt occurs, the fifth
nested function call inside the interrupt service routine will overwrite the user programs
bottom level of stack. This is dealt dealt with by the front end when the user submits a
file for compilation. The post-compilation listing file is parsed for the compilers estimate
of stack usage.
6.3.3
Interrupts
The user program cannot use any interrupts at all. The reason being that the
bootloader uses interrupts (for the ping timer and for TCP events on the S7600A) and
thus uses the interrupt vector. Section 6.4 discusses a possible enhancement to the
SCADA Engine to deal with both user and system interrupts. The front end parses the
users source code for the string #INT at the beginning of a line preceding a function
declaration. This particular string indicates that the following function is an interrupt
handler.
6.3.4
Low Power Mode
The low power sleep functionality of the processor cannot be used. The reason for this
is that interrupts are disabled in sleep mode, and since the bootloader relies on interrupts
for its operation, putting the processor in sleep mode will prevent the bootloader from
functioning. By parsing the users source code for the sleep() command, the front
end can determine whether low power sleep mode is used in the user program or not.
The code created by the CCSC compiler automatically adds the sleep() command to
the end of the main() function to indicate the end of a program. Because of this, it
is imperative that the users code never reaches the end of the main function. This is
done by requiring the user to enclose their code in an infinite loop, or to end the main
function with an dummy infinite loop.
46
6.4
6.4. Enhancements to the SCADA Engine
Enhancements to the SCADA Engine
Although the goals set for this project were achieved with the SCADA Engine, there
are a number of areas where further work and feature development would be desirable.
6.4.1
Interrupts
Since the bootloader uses the interrupt vector, a user program cannot use any interrupts. However, since only two interrupts are actually used by the bootloader, timer0
and port B, there are still a host of other interrupts (timer1, timer2, port A, and others)
which could be made available to user programs.
In order to achieve this, the following would need to occur. Whenever an interrupt
occurs, the code would still jump to the interrupt vector which would be occupied by
the bootloaders interrupt service routine (ISR). The ISR would then check to see if the
interrupt that occurred is one of the bootloaders interrupts, and if so, call the relevant
handler. If not, it would then jump to a virtual interrupt vector which would be occupied
by the user programs ISR. This ISR would check to see if the interrupt that occurred is
one of the user programs interrupts, and if so, call the relevant user interrupt handler.
If not, the virtual ISR would return to the main ISR, which would then terminate return
control of the processor to the user program.
The ISR for the virtual interrupt vector could be implemented by the user, or could
be created on the fly by the front end by parsing the users source code to see which
interrupts are used, and then create a corresponding ISR.
6.4.2
Program Size
The 3K words of program memory available to user programs may not be enough for
some complex SCADA applications. There is very little further optimisation one might
still be able to do with the bootloader code, so a better option might be to replace the
PIC16F877 with a similar chip, but one that has more program memory. One could
either use a different make microprocessor such as an Atmel, however a simpler option
would be to replace the PIC with another Microchip PIC that is functionally similar,
such as the a microprocessor in the PIC18FXX20 family[18]. These processors offer a
program memory of up to 64K words in addition to other features such as more RAM
and IO. A third option is to use the fetch, decode and execute program model as
described in section 6.1.4.
6.4.3
Code Protection
Although the bootloader code will not download a user program that is compiled to
reside in areas of memory used by the bootloader itself, there is nothing to stop a user
47
6.5. Commercial Potential
program writing over these parts of memory once it is running. This could be done in the
same manner as the bootloader writes the user code into memory, and could potentially
render the bootloader useless.
The PIC16F877 has fuses8 which can be set to write protect parts of memory. This
can only be done with a very coarse granularity, either none, the bottom 5%, bottom
50% or all of program memory needs to be protected. Given that the bootloader code
resides in the top 1% and the bottom 51% of memory9 , the code protection options are
not particularly helpful. Theoretically, if the bootloader could be consolidated to the
bottom 50% of memory, it would prove useful - however, given that the boot vector and
interrupt vector reside at the top of memory, they cannot be write protected unless all
of memory is protected, in which case user programs cannot be downloaded. It should
be noted that no PIC microcontrollers offer a code protection option that write protects
the boot and interrupt vectors.
6.4.4
Security
The main aim of this project was to enhance the infrastructure for SCADA by
creating the SCADA Engine. Very little emphasis was placed on security aspects of the
system. Currently, any user can log onto the front end and control any active SCADA
Engine. This is obviously not an ideal situation in a production environment. Ideally,
each SCADA Engine after logging on to the back end with its unique name, would only
be able to be controlled by authorised persons. The back end and front end would need
to implement some kind of policy system allowing only authorised people to upload and
control given devices.
Users are also able to alter the unique name of their device by changing the contents of
the external EEPROM. This could become a security concern if users make their devices
imitate other devices. This issue could be overcome by using a hashing algorithm which
relies on random codes on each device which are used in a handshaking process with the
server upon initial connection.
6.5
Commercial Potential
The commercial potential for the SCADA Engine will be discussed here in brief and
will be outlined by giving a specific example situation of where and how it could be used.
Essentially, the SCADA Engine would be used in place of a custom built controller for
a given SCADA project. The SCADA Engine and GPRS module would be taken as is
and attached to a device to control or monitor. Some small amount of coding would be
8
Although called fuses, these are actually bit settings in special registers.
When all debugging code is taken out of the program. With debugging left in the bootloader, the
code takes up the top 1% and bottom 53% of memory.
9
48
6.5. Commercial Potential
done and the program would be uploaded to the device via the front end. This means
time from action to implementation is minimal, and more importantly, inexpensive.
6.5.1
Irrigation Monitoring
CSIRO Mathematical and Information Sciences have a system in place at the Allsun10
Farm in New South Wales whereby the the water level in soil is monitored remotely.
Using FullStops[3] developed by CSIRO Land and Water, the water level at various
points around a paddock is constantly monitored. When the water level exceeds a
certain point around a FullStop, the device is triggered. By monitoring the status of
6 FullStops around a paddock, the farmer can get an idea of when and how much to
irrigate, allowing the right amount of water to be applied - thus leading to less water
waste, and avoiding a rising water table (which in turn avoids salinity problems).
The FullStops at Allsun Farm are connected to a microcontroller and GSM modem
which relay the information back to the server using data calls on a regular basis. This
is where the SCADA Engine would become useful. One could attach multiple FullStops
to the SCADA Engine, as only one IO pin (plus ground) would be required per FullStop.
One would then have to write code that would monitor all of the IO pins and whenever
the voltage on one of them changes, send a message back to the server specifying which
FullStop changed state. The logic is very simple, and the messaging infrastructure is
part of the SCADA Engine. Unlike the current system, using the SCADA Engine would
provide immediate feedback when a change of state occurred with one of the FullStops.
Taking this idea one step further, when the farmer decides when and how much
to irrigate, he/she could send a message to the device requesting it to turn on the
reticulation system, which, through a relay system, could also be wired to one of the
devices IO pins.
10
See http://mobile.act.cmis.csiro.au/farm/default.asp or http://www.allsun.com.au/Allsun Farm.html

for further details.
49
CHAPTER 7
Conclusion
The results of this project demonstrate that it is possible to construct a relatively

inexpensive, easy to use and generic device for mobile supervisory control and data
acquisition, SCADA. Using only a handful of electronic components, most importantly
a PIC16F877 microprocessor, a hardware TCP/IP stack on the Seiko 7600A, and a
memory chip - all of which can be purchased on a custom made circuit board called the
Internet Engine, as well as a standard PC with an Internet connection, a system can
be created. A GPRS capable mobile phone provides a reasonably reliable continuous
connection to the Internet for the Internet Engine. Custom bootloader software has
been written for the PIC that not only allows one to reprogram the device remotely,
but provides a platform with which the downloaded program can communicate with a
server.
The server, seen by the user as a collection of web pages, provides easy access to
the functionality of the device, the SCADA Engine. The complete working system
demonstrates that a low cost, reprogrammable device for mobile SCADA is a viable
option. Such a system utilises existing infrastructure, in particular the mobile GSM
network to provide a less costly, and easier to create alternative to custom built SCADA
devices.
50
BIBLIOGRAPHY
[1] Australias
Telerobot
on
the
http://telerobot.mech.uwa.edu.au/.
Web.
[2] CCS Inc., Highly optimized PICmicro C compiler.

http://www.ccsinfo.com/picc.shtml.
WWW.
URL:
WWW, 2002.
URL:
[3] CSIRO Land Communication Group and Water. Fullstop: a simpler way to schedule
irrigation. Research Project, Sheet No. 21, May 2000.
[4] Custom Computer Services, Inc. C Compiler Reference Manual, July 2001.
[5] Dallas Semiconductor, USA. DS1629 Datasheet.
[6] E D Technical Publications, P.O. Box 541222, Merritt Island FL 32954. EDTP S7600A/PIC16F877 Internet Engine Assembly And Reference, version 1.00 edition,
January 2001. URL: http://www.edtp.com.
[7] Fred Eady. An S-7600A/PIC16F877 Journey. Circuit Cellar Online, January 2001.
Parts 1-4 available online at http://www.circuitcellar.com/online.
[8] European Telecommunications Standards Institute, 650 Route des Lucioles - Sophia
Antipolis, Valbonne - FRANCE. Digital cellular telecommunications system (Phase
2+); General Packet Radio Service (GPRS); Service description; Stage 2, January
2000. Version 7.1.1 Release 1998.
[9] Fairchild Semiconductor.
MM74HC4020/MM74HC4040 14/12 Stage Binary
Counter Datasheet, revised edition, September 2001.
[10] Nigel Goodwin.
Windows PIC Programmer.
http://www.lpilsley.co.uk/winpicprog.htm.
WWW, 2002.
URL:
[11] Francis et al Irving. TortoiseCVS - Concurrent Version Control Client. WWW,

2002. URL: http://www.tortoisecvs.org.
[12] Unidata Group Holdings Ltd. Crossramp - The Online Environment. WWW. URL:
http://www.crossramp.com.au/.
51
BIBLIOGRAPHY
[13] Kevin Mayer. IntEng Front End - Mobile SCADA Online. WWW, 2002. URL:
http://mobile.act.cmis.csiro.au/scada/.
[14] Microchip Technology Inc., Chandler AZ, USA. PICmicroT M Mid-Range MCU
Family Reference Manual, December 1997.
[15] Microchip Technology Inc., Chandler AZ, USA. PIC16F87X EEPROM Memory
Programming Specification, 2000.
[16] Microchip Technology Inc., USA. 256K I2 CT M CMOS Serial EEPROM, 2001.
[17] Microchip Technology Inc., Chandler AZ, USA. PIC16F87X Datasheet, 2001.
[18] Microchip Technology Inc., Chandler AZ, USA. PIC18FXX20 Data Sheet, 2001.
[19] Request For Comment 1661 - The Point-to-Point Protocol (PPP), July 1994. URL:
http://www.geektools.com/rfc/rfc1661.txt.
[20] Request For Comment 760 - Transmission Control Protocol (TCP), January 1980.
URL: http://www.geektools.com/rfc/rfc760.txt.
[21] Request For Comment 793 - Transmission Control Protocol (TCP), September 1981.
URL: http://www.geektools.com/rfc/rfc793.txt.
[22] et al Rekhter. Request For Comment 1918 - Address Allocation for Private Internets, February 1996. URL: http://www.geektools.com/rfc/rfc1918.txt.
[23] Richey and Humberd. Embedding PICmicro Microcontrollers in the Internet. Microchip Application Note 731, 2000.
[24] Seiko Instruments Inc., Chiba, Japan. Functional Specification - S-7600A - TCP/IP
Network Protocol LSI. Revision 0.11.
[25] Seiko Instruments Inc., Chiba, Japan. Hardware Specification - S-7600A - TCP/IP
Network Protocol LSI. Revision 1.2.
[26] Andrew S. Tanenbaum. Computer Networks. Prentice Hall, 3rd edition, 1996.
[27] Ken Taylor and James Trevelyan. A Telerobot On The World Wide Web. In
National Conference of the Australian Robot Association. Department of Mechanical
and Materials Engineering, The University of Western Australia, July 1995.
[28] T.
Teranishi.
Tera
Term.
WWW,
http://hp.vector.co.jp/authors/VA002416/teraterm.html.
1999.
URL:
[29] Unidata Group Holdings Ltd., 40 Ladner St, OConnor Western Australia 6163.
Crossramp Data Service Provider - A Technical Introduction, February 2002. Revision B.
[30] UK Vodafone. An Introduction To The Vodafone GPRS Environment And Supported Services. Vodafone, The Courtyard, 2-4 London Road, Newbury, Berkshire
RG14 1JX, December 2000. Issue 1.1.
52
Appendices
53
APPENDIX A
Communication Protocols
A.1
Server SCADA Engine
Table A.1 defines the protocol between the SCADA Engine and the back end upon
initial connection, while Table A.2 defines the communication sequence for downloading
a program to the device.
Module
Format
Meaning
Internet Engine Single line string
The unique name of of this Internet Engine
Controller
An integer between The port which the Internet Engine should
1024 and 65536
connect to the back end on for the data
channel.
Table A.1: Communications Protocol - Initial Connection of SCADA Engine to Server.
Module
Controller
Format
D
Controller
;, A-F, 0-9
Internet Engine
One of 1, 3, 4
Meaning
A line with the first character as D is used
to indicate to the device that a download
follows (otherwise it is assumed to be a ping
packet).
The contents of the Intel HEX file (the
compiled program) is transmitted one line
at a time.
An indication of the result of the download.
The responses mean; (1) the download was
successful, (3) the download was too large
to fit in memory, and (4) the download
timed out and was aborted.
Table A.2: Communications Protocol - Uploading a Program to a SCADA Engine.
54
APPENDIX A. Communication Protocols
A.2
Front End Back End
The front end makes one of the requests described in Table A.3. The definitions of
the XML documents referenced in the table follow.
Situation
A query to find out a list of
available devices.
Front End Says...

DEVICES
The user wants to upload a

HEX file to a given device.
UPLOAD
<# LINES IN XML>
<XML - HEX FILE>
To check the last status of a

given device (the controller
for the device will have information about what was
last performed).
STATUS <DEVICENAME>
To send a message to the

user program through the
data channel.
SEND
<# LINES IN XML>
<XML - MESSAGE>
Back End Says...

N
<DEVICENAME 1>
<DEVICENAME 2>
..
.
<DEVICENAME N>
0 (device not available)
1 (file uploaded successfully)
3 (file too large to fit
into memory)
102 (an IO error occurred)
1 (upload in progress)
2 (last upload complete/device active)
10 (an error occurred
during the last upload)
-1 (XML is badly
formed)
1 (message delivered)
Table A.3: Communications Protocol - Front End Back End.

Although no schemas or DTDs were written up for the XML documents used, the
formats are obvious from the examples given.
A.2.1
XML Message To Device
<?xml version="1.0"?>
<message>
<timestamp unixtime="[# SECONDS SINCE THE EPOCH]"/>
<address to="[DEVICE NAME]" from="[IP ADDRESS OF USER]"/>
<contents>up to 4096 bytes may appear here</contents>
</message>
A.2.2
XML File For Upload
The front end passes the back end an XML file ready for upload encapsulated as an
XML document as follows:
55
APPENDIX A. Communication Protocols

<?xml version="1.0"?>
<hexfile destination="[DEVICE NAME]">
<line>:1025C0000319B10A0319B20A0319B30A2B300C1EFE</line>
<line>:1025D000E72A990060300317970003130B080B05D7</line>
<line>:1025E0008B13A0000A128A1539200A168A112008B6</line>
<line>:1025F0008B0478084139003A031D852AB7010A1275</line>
<line>:102600008A154C2F0A168A11002864300317960089</line>
<line>:1026100003130B080B058B13A0000A128A156920FF</line>
<line>:0C2620000A168A1120088B0409296300A7</line>
<line>:02400E003A3F37</line>
<line>:00000001FF</line>
<line>;PIC16F877</line>
</hexfile>
Note that the very last line element is optional as it does not contain code, but
simply lists the name of the device the file was compiled for. It is never actually uploaded
to the device if it is included.
56
APPENDIX B
Source Code
The complete CVS tree used for this project can be found on the attached CD.
This includes all of the source code for the bootloader, the front end, the back end and
the sample SCADA application - tempdemo. The bootloader code conforms to the the
CCSC version 3.072 compiler specifications, the back end conforms to the Java Runtime
Environment version 1.4 and the front end conforms to PHP 4.1.2.
The file index.html, located in the root directory of the CD-ROM, contains explanatory notes and links to all of the relevant source code files used for this project.
57
APPENDIX C
Memory Overview
C.1
Program Memory
A total of 8KB of EEPROM is provided for code in the PIC16F877. On power up,
the program counter is set to zero, this is the address of the boot-vector. The interrupt
vector is located at address 4 (0x0004) and thus programs must use the boot-vector to
implement a jump to the location of the main program. Naturally, the bootloader uses
the boot-vector and the interrupt vector as is necessary. The bulk of the bootloader
though is located at the end of memory as shown in figure C.1.
Boot vector (bytes 03)
Interrupt vector (bytes 4
to ~100)
oK
0x0000
PAGE I
2K
0x0800
PAGE II
4K
Boot loader code

Including:
+ interrupt handler
routines
+ system calls such as
_send_message()
0x1000
PAGE III
6K
0x1800
PAGE IV
8K
0x1FFF
Shaded area of memory is used by the bootloader,
non shaded area is where a user program would
be located.
Figure C.1: Memory Map of Program EEPROM Usage

All of the space in memory not used by the bootloader is available for user programs.
C.2
Data Memory
The 256 bytes of data EEPROM inside the PIC chip is not used by the boot loader
and thus fully available to user programs. The 24LC256 provides a further 32KB for data
58
APPENDIX C. Memory Overview

storage. The boot loader utilises the last 512 bytes of this space to store parameters that
may vary between situation. Figure C.2 shows a memory map of the external EEPROM.
The contents of memory starting at address 0x7E00 for an example SCADA Engine
using the Motorola Timeport 8379i is given below. Note that the IP address is written
in hexadecimal, rather than the conventional xxx.xxx.xxx.xxx notation. Since many
ASCII characters are non-printable (for example, the bell character), they are simply
not printed below, all blank spaces after a null character can contain anything. Special
characters such as the line feed and carriage return are represented using standard
escaped notation (\n is line feed, \r is carriage return and \0 is the null character).
Address
0x7E00
0x7E40
0x7E80
0x7EC0
0x7F00
0x7F40
0x7F80
0x7FC0
Memory Contents
AT&F\n\r@AT+CGDCONT=1,"IP","telstra.internet","0.0.0.0",0,0\n\r@AT
+CGQREQ=1,0,0,0,0,0\n\r@AT+CGQMIN=1,0,0,0,0,0\n\r@AT\n\r@AT&F\n\r@AT V
1E0S0=0&D2&C1\n\r@AT+CMEE=1\n\r@ATS7=60;+DS=3,0,2048,32;IFC=2,2\n\r@AT
D*99#\n\r\0
985359C913My Name is Jack\0
MyUsername\0MyPassword\0
This area of memory is currently not used by the bootloader but may prove
useful in the future to store more options.
Contents of message to send to the server

Contents of message received from the server
oK
1K
2K
0x0000
0x0800
0x1000
8K
0x2000
16K
0x4000
64 bytes
AT commands required to initiate PPP
with the GPRS module. Can include any
ASCII characters, but @ is reserved as
a delay signal. End of commands is
marked by a null (0x00) character
IP Port
24K
0x6000
32K
0x7E00
0x7FFF
Shaded areas are reserved.

Non shaded area is available
for use by user program.
Device name (end with null)
PAP username+null+password+null
IP address is
given 4 bytes
Port is given 2
bytes
Figure C.2: Memory Map of the External EEPROM Usage
59
0x7E00
0x7EFF
0x7F3F
0x7F7F
0x7FFF
APPENDIX D
Hardware Schematics
D.1
The Internet Engine
A photograph of the Internet Engine with rule measurements included is shown in

Figure D.1.
Figure D.1: The Internet Engine and its Dimensions

The schematics for the Internet Engine are presented in figures D.2, D.3, D.4, D.5
and D.6, are reproduced with the permission of their creator, Fred Eady.
60
APPENDIX D. Hardware Schematics
Figure D.2: Schematic - Serial Connection to the PIC16F877
Figure D.3: Schematic - PIC16F877 and its Connections
61
Figure D.4: Schematic - S7600A and its Connections
Figure D.5: Schematic - Serial Connection to the S7600A
62
Figure D.6: Schematic - All Other Components
D.2
Dontronics DT001 PIC Programmer
The PIC programmer used on the Internet Engine is shown in figure D.7. Further
details on the programmer and how to obtain one are available from the Dontronics
web-site, at http://www.dontronics.com/dt001.html.
Figure D.7: The Footprint of the Dontronics DT001 PIC Programmer
63
APPENDIX E
Project Plan
The project plan that was drawn up for this project as part of the course requirements for ENGN3221, Project and Operations Management at The Australian National
University is included on the accompanying CD-ROM. The file index.html, located in
the root directory of the CD-ROM links to the relevant files.
The plan has not been altered since its submission in November 2001.
64

Thesis

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Thesis

Diunggah oleh

Hak Cipta:

Format Tersedia

Over the Air Programmable

Stand-Alone Controllers Using

Kevin Benjamin Mayer

28th June, 2002

A thesis submitted in part fulfilment of the

Supervised By: Dr Zbigniew Stachurski (ANU)

2 Mobile SCADA Today

Overview of the SCADA Engine in a Production Environment . . . . . .

Pin Connections Between the Programmer and the Internet Engine . . .

Module Interaction for a no server Model . . . . . . . . . . . . . . . . .

C.1 Memory Map of Program EEPROM Usage . . . . . . . . . . . . . . . . .

The Internet Engine and its Dimensions . . . . . . . . . .

Comparison of Mobile Telephony Based Communication Methods. . . . .

Format of Database Table Used to Log Messages

Development and Production Software Required. . . . . . . . . . . . . .

Cost per 24 Hours per Device Due to Pinging. . . . . . . . . . . . . . . .

A.1 Communications Protocol - Initial Connection of SCADA Engine to Server. 54

Central Processing Unit. This is essentially part of a computer that does

The Commonwealth Scientific and Industrial Research Organisation.

A 25 pin communications connector used for serial and parallel protocols

A 9 pin serial communications connector (commonly used as the COM

File Transfer Protocol

General Packet Radio Service. This is a packet switched communication

HyperText Markup Language - the language used to describe web pages.

Input and Output

Internet Protocol. IP is a packet switched protocol which forms the basis

Internet Service Provider.

Interrupt Service Routine. This is a special routine located at the interrupt

Kilo is used as a prefix in computer terms to mean 1024 of ... Throughout

KiloBytes. This is a commonly used abbreviation in computing, where

Local Area Network [of computer].

Light Emitting Diode

A telephone exchange operated within an organisation, used for switching

Password Authentication Protocol is a popular authentication method

Point to Point Protocol. This is a protocol used to provide a means of

Public Switched Telephone Network. The standard landline telephone

Random Access Memory. This is a form of re-programmable memory that

A common serial communication protocol.

Supervisory Control And Data Acquisition.

Security Identity Module. This is a smart card used in mobile phones to

Structured Query Language. SQL is a popular language used for querying

Transmission Control Protocol. This is the primary connection oriented

eXtensible Markup Language is a method of encapsulating data in a way

SCADA, Supervisory Control And Data Acquisition, is a relatively simple concept,

in the house tripped, and at what time.

Like many technological developments, the drive behind improvements in SCADA

reach of many businesses that previously found SCADA too costly.

By creating a single device that can be used in many different circumstances, we

I/O channels to peripherals

User wishing to install a

Figure 1.1: Overview of the SCADA Engine in a Production Environment

Figure 1.2: Scope of the Project

CHAPTER 2. Mobile SCADA Today

2.1. Competing Technologies

See http://www.globalstar.com for further details.

CHAPTER 2. Mobile SCADA Today

2.2. Related Technologies

Australias Telerobot on the Web

CMIS and Communication Methods

Table 2.1: Comparison of Mobile Telephony Based Communication Methods.

CHAPTER 2. Mobile SCADA Today

2.2. Related Technologies

Single Bit Communication

An implementation of this is available at http://mobile.act.cmis.csiro.au/sms/editActions.asp