Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
5
5
3.1
3.2
3.3
15
15
25
6.1
38
58
59
D.1
D.2
D.3
D.4
D.5
D.6
D.7
60
61
61
62
62
63
63
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
LIST OF TABLES
2.1
3.1
. . . . . . . . . . . . .
24
4.1
30
6.1
42
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
CSIRO
DB-25
DB-9
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
GPRS
vi
DEFINITION OF ACRONYMS
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
IO
IP
ISDN
Integrated Services Digital Network. ISDN lines are used by many companies for data and/or multiple voice line connections.
ISP
ISR
K or k
KB
LAN
LED
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
PAP
PPP
PSTN
vii
DEFINITION OF ACRONYMS
RAM
RS-232
SCADA
SIM
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
TCP
XML
viii
CHAPTER 1
Introduction
1.1
Definition
CHAPTER 1. Introduction
1.2. Motivation
1.2
Motivation
CHAPTER 1. Introduction
1.3. Goals
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.
CHAPTER 1. Introduction
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
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
CHAPTER 1. Introduction
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
SCADA
Engine
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
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
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
2.2
Related Technologies
2.2.1
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
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
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.
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
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
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
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.
3.1. Theory
3.1.3
GPRS Module
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
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
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
Front end
listenner
Device
listenner
Controller
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.
Internet Engine
User program
Bootloader
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
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
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.
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
CHAPTER 4. Implementation
4.2. Method
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
CHAPTER 4. Implementation
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
CHAPTER 4. Implementation
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
CHAPTER 4. Implementation
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
35
CHAPTER 5. Results
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
Telstra is used as a benchmark as they provide the largest GSM network in Australia.
37
CHAPTER 6. Discussion
38
CHAPTER 6. Discussion
6.1.2
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
CHAPTER 6. Discussion
6.1.4
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
CHAPTER 6. Discussion
6.1.5
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
CHAPTER 6. Discussion
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)
6.2
Communication Protocols
6.2.1
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
CHAPTER 6. Discussion
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
CHAPTER 6. Discussion
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
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
CHAPTER 6. Discussion
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
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
CHAPTER 6. Discussion
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
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
CHAPTER 6. Discussion
6.4
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
CHAPTER 6. Discussion
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
CHAPTER 6. Discussion
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
49
CHAPTER 7
Conclusion
50
BIBLIOGRAPHY
[1] Australias
Telerobot
on
the
http://telerobot.mech.uwa.edu.au/.
Web.
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:
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
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.
54
A.2
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.
UPLOAD
<# LINES IN XML>
<XML - HEX FILE>
STATUS <DEVICENAME>
SEND
<# LINES IN XML>
<XML - MESSAGE>
A.2.1
<?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
The front end passes the back end an XML file ready for upload encapsulated as an
XML document as follows:
55
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
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.
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
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.
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
PAP username+null+password+null
IP address is
given 4 bytes
Port is given 2
bytes
59
0x7E00
0x7EFF
0x7F3F
0x7F7F
0x7FFF
APPENDIX D
Hardware Schematics
D.1
60
61
62
D.2
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.
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