BRIO

c cc c
.
Net
:
A Vending Machine on the Internet
Written by
Nathan Christopher Roche
Department of Computer Science and Electrical Engineering
University of Queensland
Submitted for the degree of Bachelor of Engineering (Honours)
in the division of
Computer Systems Engineering
October 1999
Registered Trade Name of the Coca-Cola Company
University of Queensland c cc c.Net: A Vending Machine on the Internet
I Nathan Roche
Nathan Roche
76 Spring St
Deception Bay, Q 4508
Tel. (07) 3203 2150
18
th
October 1999
Professor Simmons
School of Engineering
University of Queensland
St Lucia, Q 4067
Dear Professor Simmons
In accordance with the requirements of the degree of Bachelor of Engineering
(Honours) in the division of Computer Systems Engineering, I present my thesis
entitled "Coke.Net: Vending Machines on the Internet". This works was performed
under the supervision of Dr. Mark Schulz.
I declare that the work submitted in this thesis is my own, except where noted
in the text and footnotes and has not been previously submitted for a degree at the
University of Queensland or any other institution.
Yours Sincerely,
Nathan Roche
II Nathan Roche
Acknowledgments
I would first and foremost like to thank my thesis supervisor, Dr. Mark Schulz, for
being a constant source of guidance and encouragement throughout the duration of
my thesis project. I would also like to express my sincere appreciation of the
supervisor of the thesis laboratories, Mr. Leonard Payne, who has been very kind in
offering his advice on many occasions during the year.
My thanks also go to Coca-Cola Amatil for providing me with a vending machine for
the duration of this thesis project.
And last, but definitely not least I would like to express my heartfelt gratitude for my
family and all of my friends who have supported me throughout the most trying year
of my academic experience. In the words of Jeff Fenech, "I love yas all!".
III Nathan Roche
Abstract
In recent years the concept of network devices on the Internet has been used in a wide
variety of applications, to suit many different purposes. One purpose that is very
suited to the use of an Internet device is the monitoring of vending machines. By
interfacing the machine to the Internet the owner/operators of vending machines
stands to gain substantially. This is because this technology would take all of the
'guess work' out of the vending industry. Where once many people would be needed
to make on-site visits in order to check the current status of vending machines, one
person, in a central location could now do this for an entire network of vending
machines simply by viewing a web site. Another advantage of this idea is that it can
run on any computer platform that supports a web browser application.
This thesis, entitled "Coke.Net: A Vending Machine on the Internet", goes about
designing a system which could be used to monitor the status of any type of vending
machine, with only minor adjustments to certain parameters, via the internet. In order
to achieve this goal, a web server was implemented using a 486 PC running the Red
Hat Linux 6.0 operating system. A program that reads sensor values via a parallel
port interface is used then to interpret the status of the vending machine.
Since this thesis aims to provide for an entire industry, specific pains have been gone
to keep the design independent of particular vending machines. This design has been
built and tested and meets the aims of the thesis.
IV Nathan Roche
Contents
ACKNOWLEDGMENTS ....................................................................................................................II
ABSTRACT......................................................................................................................................... III
LIST OF FIGURES........................................................................................................................... VII
LIST OF TABLES........................................................................................................................... VIII
TABLE OF NOMENCLATURE....................................................................................................... IX
CHAPTER 1 - INTRODUCTION........................................................................................................ 1
1.1 The Aim of the Thesis ............................................................................................................... 4
1.2 Overview of this Thesis Document ...........................................................................................5
CHAPTER 2 - PRODUCT REVIEW.................................................................................................. 7
2.1 The UCC Drink Machine [1] ................................................................................................... 7
2.2 SACM Coke Club [2] ............................................................................................................... 8
2.3 Online Vending Machines at DIKU [3] ................................................................................... 9
2.4 Paul Haas's Internet Devices ................................................................................................. 10
2.4.1 Network Refrigerator ..................................................................................................................... 11
2.4.2 World-Wide-Web Hot Tub ............................................................................................................ 11
2.4.3 Desktop Environment Device on the Internet ................................................................................ 12
2.5 Discussion of Characteristics................................................................................................. 13
CHAPTER 3 - DEVELOPMENT OF PRODUCT SPECIFICATION........................................... 15
3.1 High Level Specifications....................................................................................................... 15
3.2 Hardware Sub-system Specifications ..................................................................................... 17
3.2.1 Sensors........................................................................................................................................... 18
3.2.1.1 Stock Level Sensors............................................................................................................... 18
3.2.1.2 Vandalism Sensor .................................................................................................................. 18
3.2.2.3 Internal Temperature Sensor.................................................................................................. 18
3.2.2 Glue Logic Layer ........................................................................................................................... 19
3.2.3 Processor........................................................................................................................................ 19
3.2.4 Network Connection ...................................................................................................................... 20
3.2.5 Memory requirements .................................................................................................................... 20
3.3 Software Sub-system Specifications........................................................................................ 20
3.3.1 Operating System........................................................................................................................... 21
3.3.2 Web Server..................................................................................................................................... 22
V Nathan Roche
3.3.3 Interface Software.......................................................................................................................... 22
CHAPTER 4 - HARDWARE DESIGN/IMPLEMENTATION ...................................................... 23
4.1 Vending Machine.................................................................................................................... 23
4.2 Sensors ................................................................................................................................... 24
4.2.1 Temperature ............................................................................................................................ 24
4.1.2 Stock Level ................................................................................................................................... 25
4.1.2.1 Generating Dispense Signals ................................................................................................. 25
4.1.2.2 Generating Refill Signals....................................................................................................... 26
4.1.3 Vandalism...................................................................................................................................... 26
4.2 Processor and Support Hardware.......................................................................................... 27
4.3 Connecting to the Internet ...................................................................................................... 28
4.4 Interfacing sensors to the PC................................................................................................. 29
4.4.1 Glue Logic Layer ........................................................................................................................... 29
4.4.2 PC Data Interface Layer................................................................................................................. 30
CHAPTER 5 - SOFTWARE DESIGN/IMPLEMENTATION........................................................ 32
5.1 Operating System: .................................................................................................................. 32
5.2 Web Server ............................................................................................................................. 33
5.3 Interface Software .................................................................................................................. 34
5.3.1 Hypertext Transfer Protocol Considerations [8] ............................................................................ 34
5.3.1.1 Push Technology versus Automatic Refresh.......................................................................... 35
5.3.2 HTML Structure............................................................................................................................. 37
5.3.3 Email.............................................................................................................................................. 38
5.3.4 CGI-scripts..................................................................................................................................... 39
5.3.5 Logging Changes: .......................................................................................................................... 39
CHAPTER 6 - RESULTS.................................................................................................................... 41
6.1 High Level System.................................................................................................................. 41
6.2 Hardware Sub-system............................................................................................................. 42
6.3 Software Sub-system............................................................................................................... 43
CHAPTER 7 - DESIGN REVIEW..................................................................................................... 45
7.1 Future Developments.............................................................................................................. 45
7.1.1 Control Features............................................................................................................................. 45
7.1.2 Hardware Improvements................................................................................................................ 46
7.1.3 Software Improvements ................................................................................................................. 47
7.2 Personal Performance............................................................................................................ 47
CHAPTER 8 - CONCLUSION........................................................................................................... 49
REFERENCES..................................................................................................................................... 50
VI Nathan Roche
APPENDIX A....................................................................................................................................... 52
PRINTED CIRCUIT BOARD ARTWORK................................................................................................. 52
APPENDIX B....................................................................................................................................... 54
ALTERA DESIGN ................................................................................................................................ 54
APPENDIX C....................................................................................................................................... 70
CODE LISTINGS: ................................................................................................................................. 70
HTML code: ................................................................................................................................. 71
CGI-Script .................................................................................................................................... 72
C Programs .................................................................................................................................. 82
VII Nathan Roche
List of Figures
Figure 1 - Concept for an Online Customer Service Tool ............................................ 2
Figure 2 - Example of an Internet-Ready Vending Machine Network......................... 3
Figure 3 - The UCC System, inside the drink machine and profile.............................. 8
Figure 4 - DIKU "Cokeserver" and vending machine sensor circuitry....................... 10
Figure 5 - Example of the HTML return of a refrigerator query ................................ 11
Figure 6 - Internet controlled waving hand and its control web page......................... 13
Figure 7 - Block diagram of the entire system............................................................ 15
Figure 8 - Block Diagram of Hardware Sub-System.................................................. 17
Figure 9 - Software Flow Diagram ............................................................................. 21
Figure 10 - The Coca-Cola vending machine used in the System.............................. 24
Figure 11 - DS1620 Functional Block Diagram........................................................ 25
Figure 12 - Functional diagram of vandalism sensor.................................................. 27
Figure 13 - Block Diagram of PC Interface ................................................................ 29
Figure 14- Basic operation of a web server................................................................. 35
Figure 15- Push technology functional diagram......................................................... 36
Figure 16 - Coke.Net main web page.......................................................................... 38
VIII Nathan Roche
List of Tables
Table 1 - System I/O................................................................................................... 17
Table 2 - Sensor Outputs to Glue Logic Outputs ........................................................ 30
Table 3 - Parallel port mapping of glue logic outputs................................................. 31
Table 4 - Parallel port output signals .......................................................................... 31
IX Nathan Roche
Table of Nomenclature
HTTP Hypertext Transfer Protocol
HTML Hypertext Markup Language
PC Personal Computer
OS Operating System
PCB Printed Circuit Board
I/O Input and Output
RAM Random Access Memory
EPROM Eraseable Programmable Read Only Memory
EPLD Eraseable Programmable Logic Device
NIC Network Interface Controller
CGI Common Gateway Interface
Nathan Roche Page 1
Chapter 1
Introduction
The Internet has become an everyday part of modern society and as its popularity
continues to grow, so do the technologies that make use of it. One technology that
stands to benefit greatly from this rapid expansion is the vending machine. In
particular an opportunity to remotely control and monitor the status of a network of
vending machines, by way of the Internet, exists. The benefits of such a system are
numerous, but for the most part can be separated into two main categories. These two
groups are the owner/operator of the vending machines and their patrons..
The implementation of such a system would provide potential customers with a
valuable information tool. In simple terms it would allow them to find out the status
of a given vending machine from the comfort of their home or office. A potential
customer would simply navigate a central web site, using any recent graphical web
browser, and be able to find the nearest vending machine stocking a particular
product with reference to a given location.
In order to do this, the web site would only need to take input from the user
concerning their position (perhaps through the use of a graphical city map), and the
nature of their query (See Figure 1.0). From this point the information would be
processed and the user would be linked to a web page containing the details of the
nearest relevant vending machine. In addition to this the customer would be provided
with information on the current state of the machine. Such information could include
the number and type of products available in the vending machine, how hot or cold
the products are, and the price of these products. By implementing such a service it is
believed that more of these casual users would indeed become regular customers.
Nathan Roche Page 2
Figure 1 - Concept for an Online Customer Service Tool
While this system would make for an excellent customer information tool, its
applications are even more useful when viewed from a maintenance perspective. By
implementing such a system all of the guess work would be taken out of the
vending industry. Critical information, such as stock levels, vandalism and general
fault reports, would be able to be brought to the attention of the vending machine's
owner/operator in almost real-time. Not only would this information be able to be
displayed on a web-browser, but it would allow the vending machine to send e-mail
to its servicer, when it requires attention. It would also be possible for each vending
machine to log changes in status to a file. In this way the owner of the vending
machines would be able to identify trends both locally (i.e. at specific vending
machines) and globally (i.e. across the whole vending machine network), within just a
few moments.
In addition to providing information on the status of the vending machines, this new
technology would allow the owner/operator to make certain changes to the settings of
the vending machine remotely. For instance settings such as the price of certain
products and the refrigeration levels of the machines would be able to be changed
Nathan Roche Page 3
from one remote central control point. This would save the owner of the vending
machine time and money.
One of the major benefits of this system, both for the owners and customers of the
vending machines, is that it does not require any purpose-built user-end software to
be installed. Any computer with an Internet connection and a recent graphical web
browser would be able to access the information given by the system. Furthermore by
utilising the connection between the vending machine and the Internet updates to
software running on the vending machines can also be made remotely.
Figure 2 - Example of an Internet-Ready Vending Machine Network
Nathan Roche Page 4
This system would be relatively inexpensive to set-up and run, both in terms of a
per/machine figure, when compared to the cost of each vending machine, and with
respect to the network structure as a whole. This would be particularly useful as it
encourages a widespread approval of the system.
1.1 The Aim of the Thesis
This aim of this thesis project is to implement a device responsible for observing the
status of a single vending machine. This implementation will be able to serve as a
tool for both user information and machine maintenance. This device will be able to
report the stock levels of the vending machine, the machine's internal temperature,
and the relative temperature of each product. In addition to this a method for
detecting vandalism to the machine will also be implemented.
This device will interface this information to the Internet, and will be represented in
two ways. The first way in which the information will be represented is as a web-site,
capable of being viewed in any recent graphical web-browser. The second
representation is as email reports sent from the machine during the occurrence of pre-
determined events. In addition to this, data pertaining to the machines sale patterns,
and vandalism reports will also be logged and stored as a file capable of being be
downloaded from the previously mentioned web-site. In doing this it is expected that
the overall usefulness of such a device will be shown, thereby hinting at the
usefulness of a network of vending machines.
As stated in the previous section of this chapter, the cost of the Internet device is to be
kept low (i.e. a few hundred dollars compared with the cost of the vending machine).
Nathan Roche Page 5
1.2 Overview of this Thesis Document
This document describes the way in which this thesis project took shape and how the
various aspects of this design were identified and dealt with. Wherever possible,
diagrams have been used to highlight the point of the text, and illustrate the way in
which problems were solved.
The next chapter of this document, the product review, examines some of the
products that relate to the aims of this thesis. From these products, key characteristics
will be identified, in order to classify the different areas of this thesis project which
need to be addressed.
Chapter three of this document sets out specifications for the thesis. These
specifications are developed from the characteristics identified in a discussion of the
product review. While these specifications deal with the system as a whole, they also
describe the project at a much lower level. In this section specifications for both the
hardware and software aspects of this project are detailed. All inputs and output to
the system, on all of its different levels, are put forth in this chapter, and it is an
imperative part of thesis project as a whole.
It is from these specifications that the design implementation of the thesis aims is
built. Chapters four and five of this document, respectively, give the details of both
the hardware and software aspects of this implementation. These chapters describe
what decisions were made and why they were made with reference to the
specifications. These chapters explain in full how the aims of this thesis have been
brought to reality, as a working prototype for future designs.
Chapter six of this document rate the results of this thesis project against the aims set
down in the noted at the beginning of the thesis. The performance is measured by
attaining whether or not the specifications for the project have been met and how far
the final design deviates from the high-level design of the system. Also given
Nathan Roche Page 6
consideration is whether a better design could have been reached while still meeting
the specifications set down at the beginning of the document.
The design aspects of this project have been reviewed in the seventh chapter. In
particular it speculates as to what the design would look like if it was developed again
with the insight gained from the initial implementation. This chapter also examines
the possibilities for extensions to this project, providing examples of just what could
be incorporated into future designs. Apart from the actual implementation of the
thesis project the design review section also looks at the design process. In this
section reflection is given on the author's overall performance as a design engineer.
The final chapter of this document gives a summary of the thesis as a whole. This
summary reiterates the important aspects of this thesis, and this concludes the
document.
Appendices containing the hardware designs, PCB artwork, HTML texts and code
listings have been included as an attachment to the back of this thesis document,
allowing the reader to peruse the finer detail of the thesis design.
Nathan Roche Page 7
Chapter 2
Product Review
Whenever an engineering project is started, it is important to fully research any
relevant information. A very useful type of research is to review some of the
products already in existence, which relate to the goals of the project. The product
review helps to identify the characteristics of these products. This information is very
useful for deriving the specific characteristics for the project at hand.
The products reviewed below are either projects involving vending machines on the
Internet, or different types of Internet driven/monitored devices. At the conclusion of
these product reviews, a brief summary is given highlighting any common
characteristics shared by these products.
2.1 The UCC Drink Machine [1]
This particular vending machine on the Internet project was developed by the
University Computer Club (UCC), of the University of Western Australia, and began
in 1992. The vending machine used for the project was a Coca-Cola drink vending
machine. The status of the Coke machine can be polled by using the unix "finger"
command on the Coke machines address (i.e. finger coke@gu.uwa.edu.au).
The purpose of this vending machine's Internet interface is to allow users to purchase
drinks from the machine without using hard currency. That is, the users sets up an
account with an appointed cokemaster, by paying a given amount of money. In
order to use this account a person simply types their account details into the terminal
Nathan Roche Page 8
located directly next to the vending machine. This terminal consists of a test monitor
networked to a Sun running UNIX. Upon verification of the account's validity, the
controller board inside the vending machine receives a request and it is processed
accordingly.
If a drink is dispensed then acknowledgment of this is sent back to the network and
the user's account is updated. However if it is not able to process the request, it then
notifies the user and the account is left as it was. The controller board for the Internet
interface essentially consists of an 8MHz 68000 board with 16K EPROM, 64K
SRAM, and a 68681 DUART. It also has several I/O ports (using the 74LS373 and
74LS244 chips), which processes information from both the network and the sensors
inside the vending machine (See Figure 3).

Figure 3 - The UCC System, inside the drink machine and profile
2.2 SACM Coke Club [2]
The student chapter of the Association for Computing Machinery (SACM) at the
University of Wisconsin has developed another vending machine accessible via the
Nathan Roche Page 9
Internet. The SACM project combines Internet technology with a Coke machine, in a
similar manner to the UCC drink machine described above, and operates on a similar
system. That is, the students on campus can open a Coke account into which deposits
of any amount can be made. Each time a drink is purchased, the cost of the drink is
deducted from the account.
Some of the more interesting features that have been implemented in this project take
advantage of the network platform. For example funds in one user's account can be
transferred to another user. Also the Coke machine will automatically e-mail a user
when a deposit is made, money is transferred, or an account is running low on funds.
This machine may also be "fingered" from a dedicated web page in order to report its
status. The computing power behind SACM system is a Digital Celebris XL 590 with
64MB of RAM using a 90Mhz Pentium processor. The operating system running on
this hardware platform is SunOS 5.1.1.
2.3 Online Vending Machines at DIKU [3]
A group of university students from the Department Of Computer Science at the
University of Copenhagen (DIKU) have also connected vending machines to the
internet. In this particular case the system is comprised of two vending machines.
These are a Coke machine and a Faxe Kondi Drink Machine.
Only one web server is used to monitor both machines, due to their close vicinity to
each other. This server consists of a 486DX 33 PC with 8 Megabytes of RAM
running the Linux operating system. Other PC peripherals used in this project were a
Cirrus Logic 5420 VESA display adapter, a NE2000 ISA network adapter, and a
210Mb Western Digital IDE Harddisk (See Figure 4).
Nathan Roche Page 10

Figure 4 - DIKU "Cokeserver" and vending machine sensor circuitry.
The status of the machine is measured by monitoring the sale LEDs on the vending
machines. The values of these LEDs, (i.e. on or off), is read by the PC using a
parallel port interface developed specifically to suit the task. This purpose of this
project is to allow people to be able to view the stock levels of the products within the
machine, and the temperature of the stock.
2.4 Paul Haas's Internet Devices
While the vending machines on the Internet reviewed earlier in this section provide
some useful information, in reference to the aims of this thesis, other devices on the
internet were also examined. A particularly good example of these devices is the
projects put together by Paul Haas. Although these devices serve a number of
purposes, they all communicate with a central server. The processor used for this
server is a Sun 3/50 with 8 Megabytes of RAM, which runs the SUNOS 4.1.1
operating system. The web server program used on this hardware is NCSA httpd 1.3.
The majority of the software that runs these Internet devices was written in either Perl
or C. A summary of his projects and their main features is given below.
2.4.1 Network Refrigerator
One of these projects reports on various aspects of Paul's refrigerator. The way in
which this report is given, as with all of his projects, is by generating a HTML page
upon receipt of a HTTP request (See Figure 5). This device is used to tell the
temperature of the inner compartment of the refrigerator and also the temperature of
the freezer compartment, and a can of Diet coke. As well as this the device senses
whether the door is open and if the light is on inside the refrigerator. This was done
using a Motorola 68HC11 with 256 bytes of RAM and 2048 bytes EEPROM which
communicates with the server using the PC's serial port. The temperatures are all
measured using thermisters in combination with the ADC inside the 68HC11
microprocessor.
Figure 5 - Example of the HTML return of a refrigerator query
2.4.2 World-Wide-Web Hot Tub
This device is implemented in a remarkably similar way to the refrigerator project, in
that it also uses a 68HC11 microprocessor with 256 bytes of RAM and 2048 bytes of
EEPROM to communicate the sensor findings to the server. This device uses an
Internet interface to impart information about a hot tub. This is used to determine the
following:
the temperature of the hot tub
whether the ozone generator is working
whether the light is on
whether the backup battery is plugged in.
2.4.3 Desktop Environment Device on the Internet
While the purpose of this project is largely a novelty factor, it goes a long way in
showing what can be achieved with minimal hardware and very basic software. In
contrast to the previous projects this device allows a user to cause a remote action as
well as observe the environment in which the device is located.
The hardware used in this project consists of a Parallax Inc. Basic Stamp micro-
controller, a Dallas DS1620 temperature sensor and a service motor. This device
allows a user to see the temperature of Paul's desktop work-space and to wave a card-
board cut-out hand located on top of the server (See Figure 6).

Figure 6 - Internet controlled waving hand and its control web page
2.5 Discussion of Characteristics
The majority of the products reviewed in this chapter have used a PC to run a web
server program, in combination with external sensor hardware. The sensor hardware
is used to gather status information from the vending machine, and this is
communicated to the PC by way of an interface circuit of some description. For the
most part these products use an ISA network interface control adapter card to make
the necessary network connection.
Of the vending machines interfaced to the Internet, which were reviewed, a
commonality of purpose was found. That is the reason for the systems is to allow the
vending machine users to check the stock levels of the machine. Each system also
allowed these people to open an account that is maintained over a closed network,
which they can use to make purchases at the machine.
While none of these Internet vending machines focus on the maintenance of the
machine, it is easy to see how these systems, and their related implementations could
suit the aims of this thesis.
It is also worth noting that nearly all of these products are made up of pre-developed
parts (i.e. PC, operating system, web server program, etc), and are not designed
completely "from scratch". In simple words this means that a generic PC-based
design is favored to a highly specific design centreing around micro-controller.
Chapter 3
Development of Product Specification
Before any design can take place it is necessary that a complete set of specifications
be developed for the system. These specifications are not arrived at by chance, and to
a large extent, they are based on characteristics derived from the product review.
Figure 7 - Block diagram of the entire system
3.1 High Level Specifications
Essentially, to develop a set of design specifications for the project, the system must
first be defined at its highest level. At the highest level we have a vending machine, a
connection to an Internet gateway and an interface between the two (See Figure 7).
Since the aim of this thesis is primarily to develop this Internet interface for vending
machines, the inputs and outputs to this system need to be identified.
As stated earlier this thesis project is only concerned with the vending machine's
status and not with a means to control it. As such the system only needs to receive
output from the machine and therefore does not need a facility to output to the
machine. While this output is, to a certain extent, dependent on the particular type of
vending machine, it can for the most part be categorised into the following groups:
Stock levels information
Temperature information
Vandalism report
The way the output of the vending machine sensors varies between machines is, most
commonly, in the amount of information that is being observed. For example a
vending machine which dispenses drinks will have only a limited number of product
types stored within it (eg. 8 drink columns is equivalent to 8 product types), when
compared to a generic snack vending machine which has a great number of product
types (eg. varied chips, lollies etc.).
As such the design which is to be developed, while it will be specific to a certain type
of vending machine, must be flexible, requiring only minimal changes in order to
work with a different class of vending machines. In order to implement the most
efficient design of this thesis project which meets its aims, it is necessary that every
effort be made to reduce the number of inputs to the system. A list of all input and
output signals to the system is given in table 1
System Details I/O signals
Stock levels 2 inputs per dispensing column
Vandalism 1 input
Temperature Measurement 1 input
Network Interface Standard ethernet I/O*
*this specification is chosen to meet the conditions in the thesis laboratory
Table 1 - System I/O
3.2 Hardware Sub-system Specifications
In order to arrive at specifications for the entire hardware design, it is necessary to
understand the parts that make it up. These are the sensors to be placed in the
machine, a processor and its support hardware, a glue logic layer between the two,
and a hardware connection to a network (See Figure 8). The hardware design for this
thesis is defined by developing specifications for all of its constituent parts..
Figure 8 - Block Diagram of Hardware Sub-System
3.2.1 Sensors
The sensor types used within the vending machines, as mentioned earlier, measure
the stock levels of the products, the internal temperature of the machine, and any
incidents of attempted vandalism.
3.2.1.1 Stock Level Sensors
There are two possible methods for determining the stock levels of a given product.
Either the number of products is measured explicitly, or calculated implicitly. Of
these two options it was determined that these sensors should use the implicit method.
That is, the number of items in a certain column or stack is predetermined, and only a
dispense and refill signal, is required in order to calculate the stock level. The reason
this is done is because it requires less input signals than an explicit method, and it
does not require major changes in software to accommodate different classes of
vending machines.
3.2.1.2 Vandalism Sensor
The vandalism sensor for the system must be able to generate a pulse whenever the
machine sustains impact of a measurable level, or when the machine is tilted from its
horizontal position. The reason a pulse is to be generated whenever this activity takes
place is to allow for software calibration of this sensor's output to determine whether
an act of vandalism is taking place.
3.2.2.3 Internal Temperature Sensor
Since representing temperature directly (i.e. as a binary number) would require a
great number of inputs to the system, a way of representing this value in a more
efficient manner is needed. The best way to do this is to have this sensor transmit this
value as a stream over a single input. This in turn requires a signal, triggered by
software, which indicates when this transfer is to take place.
3.2.2 Glue Logic Layer
The glue logic layer is in place to collect and interpret data from the sensors and pass
it to the processor in a form it can understand. The processor sends signals to the glue
logic layer in order to indicate when it is to clear the data it has collected from the
vending machine. The major function of this part of the glue logic design is to
represent the data from the sensors in a form that is more efficient for the processor.
Specifically the glue logic layer is to take a specific dispense or refill signal from the
vending machine and attach a binary value to it which is then passed to the processor.
This allows the processor to determine which column has either dispensed a product
or been refilled, without needing to accommodate all of the sensor signals directly.
3.2.3 Processor
The most important capability of the processor to be used within the system is
flexibility. That is, the processor must be capable of supporting any future software
upgrades, without needing hardware modification. The main purpose of this is to
allow these software upgrades to be designed and produced separately from the
system, and then implemented very quickly. In other words the processor should be
able to support a complete software overhaul (down to an operating system level),
without needing to be taken out of use. In addition to this requirement it must also be
capable of communicating with the Internet, by way of a hardware network interface.
3.2.4 Network Connection
The network connection is to be capable of interfacing to the thesis laboratory
network. Specifically this means it should use the ethernet protocol (i.e. 10 Base T).
3.2.5 Memory requirements
The hardware sub-system should contain enough memory to store the software
needed to run the system, the HTML files which are generated by the system, and any
images which are to be included within said HTML files. In addition to this the
memory should be large enough to accommodate future changes in the system, such
as log files, a more extensive web site structure, and any other necessary software.
While it is not possible to put an exact value on the amount of memory to be used by
the system, the memory requirement should be met.
3.3 Software Sub-system Specifications
Equally as important as the hardware implementation of the design is the software
implementation. In simple terms the software implementation is the brains behind the
brawn. The basic responsibility of the software design is to receive input from the
sensors (by way of the hardware glue logic), and based on its interpretation of this
data, compose HTML documents, and send email reports to specified email
addresses. As well as this, the software must function as a web-server, serving the
HTML documents the system creates, to Internet clients requesting them (See Figure
9). Another requirement of the software design is that any changes in the status of the
vending machine are represented dynamically. That is, the representation of the
vending machine's status is to be updated as the changes occur.
Figure 9 - Software Flow Diagram
3.3.1 Operating System
One of the most important elements to be considered when choosing the operating
system to run on the processor used in the hardware design, is the ability to multi-
task. This is a necessity as the software design comprises many different aspects,
each serving different functions, which must run concurrently. The operating system
must also have a facility for remote user connections, so that future updates to the
software can be made, with minimum effort, allowing for an easy transition. This
becomes particularly useful when updating the software design of an entire network
of vending machines on the Internet, as it eliminates machine down-time, thus
averting any loss in revenue.
It is expected that many future updates to the software would follow the original
design release. This is because as time goes on, many new possibilities and
applications for this technology will become apparent. Therefore the operating
system must facilitate this change.
3.3.2 Web Server
As this thesis project is to be constructed with both the customers and the
owner/operators of the vending machines in mind, it is necessary that the web-server
application running on the operating system, be able to serve HTTP requests at a very
fast rate. Since it is perceivable that this system would be providing information to a
great many users simultaneously, it is necessary that the web-server applications be of
a high standard. This means that the server software would also need to be secure,
preventing the system becoming compromised (i.e. offering protection from hackers).
3.3.3 Interface Software
The interface software, in broad terms, is responsible for interpreting sensor input
and, based on this information, determining what file updates are to be made, and
when system commands should be issued. The interface software is also to interact
with the web server, by creating the HTML documents it serves to its clients, and
receiving input originating from a users web browser. This software must also log
changes in the vending machines status to a file, capable of being downloaded via a
web browser interface. Finally this section of the software is to compose email
messages in the event of certain important occurrences (eg. low stock warnings,
vandalism reports, etc.), and send them to the address of the vending machine's
owner/operator, by way of a mail server.
Chapter 4
Hardware Design/Implementation
The first part of the project design to be undertaken is the hardware implementation.
This hardware implementation is based solely on the specifications provided in the
previous chapter. It is necessary that the hardware design be completed before the
software design can be commenced. This is due to the fact that many of the software
design decisions are directly affected by the hardware implementation. The hardware
design has been outlined below in a clear and logical order.
4.1 Vending Machine
The most important hardware component in this thesis project is the vending machine
itself. While the main aim of this design strives to be independent of a particular
class of vending machines, it is still necessary that a particular machine is chosen and
incorporated in the design. The actual machine used in this thesis is a Coca-Cola
drink vending machine (also referred to as a Coke machine) donated by Coca-Cola
Amatil for the duration of this project (See Figure 10). Specifically the vending
machine has eight separate columns, which store drink bottles of 600ml capacity.
These bottles are dispensed by way of a rotating cam-shaft at the base of each
column.
Figure 10 - The Coca-Cola vending machine used in the System
4.2 Sensors
As mentioned in the specification section ( refer to 3.2.1 Sensors), sensors are needed
in order to measure the internal temperature of the machine, product dispenses,
product refills, and attempted vandalism.
4.2.1 Temperature
In order to measure temperature inside the machine a Dallas component, the DS1620
digital thermometer and thermostat, was selected. This was chosen over complex
analogue circuitry as it requires no external components, and outputs data as a digital
signal, which can be interpreted by the processor directly. The DS1620 is capable of
reading temperatures from -55
o
C through to +125
o
C, which are converted into 9-bit
binary values [5].
This particular temperature sensor solution is operated using a 3-wire serial interface,
through which data is written to and read from memory addresses within the chip
(See Figure 11). In order to read temperature, the device must first be initialised and
then sent a command requesting a temperature conversion take place. The value from
this conversion is then streamed serially down one data line of the serial interface.
This meets the specifications which states that the temperature sensor requires only
one input external to the system along which temperature information is transmitted.
Figure 11 - DS1620 Functional Block Diagram
4.1.2 Stock Level
As the specifications state, the stock level of all products within the machine is
determined by coupling dispense and refill signals with a number of predetermined
maximum stock counts. Practically this means when the system starts, it assumes
each column of the vending machine is empty until a refill signal for these columns is
received (i.e. generated when each column of the machine is restocked). Every time a
drink is sold, the system receives a dispense signal appropriate to the column from
which that drink was dropped. Determining stock levels from this point is only a
matter of simple subtraction.
4.1.2.1 Generating Dispense Signals
Dispense signals are generated whenever a drink is dropped. The way in which this
has been implemented is through the use of a micro-switch button which is depressed
only as the cam shaft at the bottom of each drink column in the vending machine,
rotates (i.e. occurring only when a drink is dispensed). These micro-switch signals
provide information pertaining to either a drink being dispensed or a column being
refilled. The Coke machine used in this project has eight individual drink dispensing
columns and hence requires eight of these signals.
4.1.2.2 Generating Refill Signals
The eight individual refill signals needed for each column of the Coke machine are
generated by a simple button interface. These buttons would be pressed by a person
servicing the machine as they restock each column to a preset level (perhaps marked
inside the Coke machine).
4.1.3 Vandalism
To ascertain when vandalism is occurring a method needs to be arrived at to sense the
ill-treatment of the vending machine. Such ill-treatment can be categorised as heavy
impact to the machine or tilting the machine beyond horizontal. Many sensors exist
which can gauge the impact on a given surface by outputting a voltage directly
proportional to the force of this impact. This type of sensor requires a voltage
amplifier and a digital to analogue converter to produce meaningful output.
Another much simpler alternative to this problem is to use a mercury-based tilt switch
which can detect an impact of given force (i.e. the force is dependent upon the angle
at which the switch is mounted), and when the machine is tilted. The tilt switch was
chosen as the system's vandalism sensor, due to its simplicity and elegance (See
Figure 12). This implementation produces just one output signal (i.e. vandalism/no
vandalism) in accordance with its specifications.
Figure 12 - Functional diagram of vandalism sensor
4.2 Processor and Support Hardware
The processor for this project is responsible for taking external signals, interpreting
them, and converting them to a form which is recognisable across an Internet
platform. The key factors examined in selecting the best processor for this thesis
project were availability, device support and finally how well the processor could
meet specifications.
The first choice to be made when choosing a processor for the system is between a
microprocessor (eg. SH1, 68HC11) or a PC-based processor (eg. X86 Series, Pentium
etc.). A microprocessor-based solution would call for a "from scratch" approach to
design. That is, the hardware design would be highly specific to a certain situation
(i.e. one class of vending machine), and would not allow a great amount of flexibility
when future changes are to be made. Conversely the PC-based processor has a very
large capacity for expansion by way of software upgrades/redesigns and replacement
of hardware peripherals. Clearly the PC-based processor is the correct choice for this
project as it best meets the criteria set down in the designs specifications.
The next decision to be made is whether a 16-bit or 32-bit processor will be used.
Given that many of the different choices of operating systems require a 32-bit
processor to function, and that many relevant software applications require these
operating systems, the 32-bit processor is the logical choice. Of these a 486 DX2-66
Processor was chosen. The reason for this particular selection was this chip possesses
remarkable processing power at a relatively low price. The support hardware chosen
for this processor was a standard 486 Motherboard with ISA slot peripheral
connections, an I/O card, a graphics card and a 210 Megabyte IDE hard-drive.
The hard drive used with the PC meets all of the specifications attributed to memory,
and its use in the system. That is, it is large enough to store all the software to be
used, while providing a great amount of room for any future changes. By using the
PC, the memory requirement became a triviality.
4.3 Connecting to the Internet
In order to communicate with clients via the Internet, a network interface is needed.
This was achieved using a generic NE2000 ISA network interface card (NIC). The
reason a NIC was chosen, and more specifically this particular NIC, is because it is
specifically designed for PC architecture (i.e. using an ISA connection), and is widely
available. Furthermore it is inexpensive and uses a widely available generic device
driver.
4.4 Interfacing sensors to the PC
In order for the PC to process data received from the sensors it is necessary that a
hardware interface between the two exists. In designing this interface it must first be
clearly defined. Upon inspection it can be seen that this interface is actually made up
of two separate parts. These are the glue logic layer and the PC data interface layer
(See Figure 13).
Figure 13 - Block Diagram of PC Interface
4.4.1 Glue Logic Layer
The first responsibility of the glue logic layer is to hold any information received
from the sensors until it is clear that the PC has dealt with it. This means that the
interface is to latch all input until the PC sends a signal clearing the latched data.
The second objective of the glue logic is to change the sensor information into a more
efficient form than that which is received directly from the sensors. As stated in the
specifications section of this document, this involves attaching a binary value to all
dispense and refill signals received, thus signifying on which column the action is
taking place. Since it is obvious that only one of the signals associated with the any
particular drink column can be active at a given time (i.e. A sale can only occur from
one column in a specific instant), the lines from these signals are multiplexed together
to produce the relevant binary column number.
The way in which the glue logic has been implemented is by using a single 44 pin
Altera eraseable programmable logic device (EPLD). This EPLD was programmed
with all of the necessary combinational logic needed to achieve the two goals just
identified. The reason for the use of an EPLD to perform this task was that it allowed
changes to be made to the logic design at a low level (as long as its inputs and outputs
stayed the same), without the need for constant reconstruction of circuits.
Sensor Outputs Glue Logic Outputs
8 Refill signals 3-bit Binary representation of active
column
8 Dispense signals Refill Signal - signifies action is a refill
Vandalism signal Dispense Signal - signifies that action is a
dispense
Vandalism Signal
Total: 17 Total: 6
Table 2 - Sensor Outputs to Glue Logic Outputs
4.4.2 PC Data Interface Layer
Data from the glue logic layer is received by the PC via the parallel port. This
interface uses the data register (output only), control register (input/output), and status
register (input only), associated with the PC parallel port to transmit and receive data
to and from the glue logic design [6]. The main reason this method was chosen for
the PC data interface is because it exploits an unused feature of the PC architecture.
[Reference]
The parallel port was chosen over the serial port, which was also available for use, as
it allowed many input/output signals to be used simultaneously. In order to use the
serial port for the purpose of a PC data interface, a complex serial communications
protocol would have needed to be developed. For these reasons the parallel port was
used. The mapping of the glue logic outputs to the parallel port is shown in the table
below:
Glue Logic Output Parallel Port Input
Column Number (3 bits) Bit 2 - Bit 0: Control Register
Refill Signal Bit 7: Status Register
vandalism
Table 3 - Parallel port mapping of glue logic outputs.
It must be noted that the temperature sensor was interfaced directly to the parallel
port, using the bit 3 of the control register as its system input. Four lines on the
parallel port were used to output to the sensors/peripheral circuitry. This has been
shown below in table 4.
Parallel Port Output Sensor Input
Data Register Bit 3 DS1620 CLK signal
Data Register Bit 2 DS1620 RST signal
Data Register Bit 1 Glue Logic Vandalism Reset
Data Register Bit 0 Glue Logic Main Reset
Table 4 - Parallel port output signals
Chapter 5
Software Design/Implementation
Following on from the description of the hardware design are details pertaining to the
software design. As mentioned in the previous section, the implementation of all of
the software aspects of this thesis, hinge on the hardware implementation. The three
major parts of the software design are the operating system, the web server program
and the PC interface program. Every decision made relating to the software
implementation of the system was given much consideration, and alternative
solutions to problems were always investigated.
5.1 Operating System:
The most obvious requirement of the operating system (OS), when consideration is
given to the processor chosen in the hardware design, is that it is to be based on a 32-
bit data path (i.e. The 486 is a 32-bit processor). The operating systems which were
examined were: DOS, Pharlap RTOS, QNX, Microsoft Windows, and Linux. Of
these choices Linux was selected. The main reasons Linux was chosen over these
other operating systems are that it is a free-licence operating system, capable of multi-
tasking, with a facility for remote login. By using this OS, changes can be made to
the software design with a minimum of hassle. The particular pedigree of Linux used
in the for the project was Red Hat Linux 6.0.
Another highly salient factor which influenced the selection of the operating system
was the amount of software available on each of these different operating platforms
(eg. compilers, web server applications, email programs). Linux has a vast amount of
free-licence software, and has a large support base. It is worth noting that this choice
meets all of the specifications set down for the operating system earlier in this
document (refer to 3.3.1 - Operating System).
5.2 Web Server
The first issue which was addressed regarding the web server software, was whether
it was to be developed from scratch, or if a pre-developed application could be
used. It was decided that a pre-developed web server application would be used.
This is due to the fact that it already incorporates the protocol needed for Internet
service. Obviously redesigning web server software is a fruitless task when it is
viable to use a fully developed working alternative.
The only fully functional web server application which is capable of running on a
Linux platform is the APACHE web server. This application is freely available and,
while it may be the only option which can be considered, it has one of the highest
performance ratings of all known web-server programs [7].
One of the goals of this project is to provide a secure, efficient and extensible server
which provides HTTP services in line with current HTTP standards. APACHE is an
open-source web server which is freely available and very easy to upgrade. It has
been used in sites which receive millions of hits per day and it performs without
problems. It is estimated that 60% of all servers on the Internet use Apache. The
major reason for this is the high level of security which is attributed to it [7]. Another
key factor to its popularity is that it "keeps pace" with an ever-changing technology
(i.e. when changes/improvements occur in internet protocols, Apache updates are
released shortly after).
5.3 Interface Software
The interface software acts as a communication layer between the sensors of the
vending machine (after glue logic) and the web server. It is responsible for creating
various HTML pages, emailing service information (eg. low stock warnings,
vandalism reports), and creating log files of all vending machine activity. It must
also be capable of receiving information from a web site. An example of this is
software that receives a user's acknowledgment of a vandalism report from a button
on a web page, and then changes the relevant HTML document accordingly.
Most of the decisions made concerning the vending machine's software interface were
directly influenced by the way in which the server operates. The main portion of this
interface was implemented as a single program that continually monitors the system.
This program was written in the C programming language.
The way in which the system determines when an action is to be executed is by
interpreting input from the Coke machine's sensors. As established in the hardware
design section, this takes place by reading and writing to the registers associated with
the parallel port of the PC.
5.3.1 Hypertext Transfer Protocol Considerations [8]
As some of the software design considerations are directly affected by the Hypertext
Transfer Protocol (HTTP), a brief summary of what this is, and how it works has
been given below.
HTTP is the standard protocol used for web transfer. In short HTTP transfers
information as a document which takes a set form. This form is known as Hyper Text
Markup Language (HTML). A typical example of how HTTP is used and what it
does is as follows:
1. A client sends a service request (for a particular HTML document), using
the HTTP protocol, to a server.
2. The server receives this and determines whether the client's request is
valid (eg. Does this information exist? Does this client have access
privileges to this information?)
3. Depending on the outcome of Step 2, the server sends the HTML
document in question to the clients web browser
Figure 14- Basic operation of a web server
5.3.1.1 Push Technology versus Automatic Refresh
Push technology is a server-side feature which allows a particular web-server to serve
a client with information at either regular or irregular gaps upon the receipt of a single
initial client request [9] (See Figure 15). This is a completely different approach to
the typical example just given, which requires the client to send an HTTP request for
each document the server sends to it.
Figure 15- Push technology functional diagram
Based on this simple description it can be seen that push technology could be used for
this thesis project, to serve a web client with an updated HTML page, showing the
status of the vending machine, only when a change in this status occurs. However
this technology, as with so many Internet features, currently has no standard and has
been implemented in many different ways. Furthermore many of these push
implementations require specific software to be installed on a client's computer before
this feature can be used.
While a feature such as push offers the system greater efficiency (i.e. information is
issued only as necessary), it does not meet one of the most basic requirements of the
project. That is, using this feature severely limits the scope of the system users.
Because push technology lacks any clear cut standard, it is not possible to view the
status of the vending machine using many different web-browsers, as implementation
of this feature is highly browser-specific.
Another alternative is the use of a "meta-refresh" statement within the HTML
document containing the vending machine's status details. This feature is contained
within the head of the document, and works very simply. After a given number of
seconds, as specified within the meta-refresh command, the clients web-browser
issues an HTTP refresh request. This is sent to the server and the server resends the
HTML file. However if this file has been changed since it was last viewed by the
client, the new file will be sent, thus showing any changes occurring in the status of
the vending machine. As long as this updated HTML file also contains the meta-
refresh statement, this process will continue.
This was the method chosen to update the users web-browser. This is in-keeping
with the requirements of the thesis project, and can be viewed by most, if not all,
recent graphical web-browsers (eg. Internet explorer, Netscape etc.).
5.3.2 HTML Structure
Due to the fact that vending machines have more than one type of status information
(i.e. Stock Levels, Internal temperature, Vandalism), it is desirable that these types
can be refreshed at different rates according to their priority. This is necessary as it
reduces the rate of HTTP requests between changes in status thus allowing a greater
number of simultaneous connections. This is important more from the customer side
of this thesis than maintenance (due to the fact that there may be a large number of
users trying to access a particular vending machine at the one time). Another reason
for reducing the rate at which HTML refreshes occur is it helps to eliminate annoying
screen flicker associated with downloading replacement HTML documents and their
associated features (pictures etc.). In order to resolve this, the web page the user
consults is built up of frames (See Figure 16). Each of these frames contains different
sections of the information (i.e. frame: Title, Stock information, Vandalism, link to
log info)
Figure 16 - Coke.Net main web page
5.3.3 Email
In order to send email, a software program, written in C, compiles the text of the
email message, including the header which contains the MIME-type information of
the message (i.e. sending address, mail-recipient, sending times etc.), and parses it to
a mailing program. This mailing program then forwards this message as an email to
the address specified. The Red Hat Linux 6.0 Operating System provides a free
mailing program upon installation. Logically this mailing program was utilised by
the interface software, to send email messages in the event of low stock, and
vandalism reports.
5.3.4 CGI-scripts
CGI-scripts are programs that perform a given task when they are called by a client in
a web environment. These tasks can be implemented using many different
programming languages, by way of shells. The most common programming shells
used for CGI-scripts are Perl and C [10].
As mentioned earlier in this section, in order for a report of vandalism to be
cleared/reset on the owner/operator's web site they must click on a button on that
page. This function was implemented using a CGI-script which changes a variable
stored in a file, when the button is clicked, and then calls the HTML source for the
page again. This variable is detected by a main C program which is responsible,
among other things for building all HTML documents.
Another CGI-script was written to handle the case of client requests for HTML
documents that do not exist (i.e. HTTP 404 Errors). This script logs the name of the
requested document and the source of this request, if possible, and issues the client
with an arbitrary page informing them of the error. Logging these requests is useful
as it provides evidence of attempted URL hacking.
5.3.5 Logging Changes:
Every time a change in the machine's status occurs, due to the sale of a drink, the
refill of a drink column or vandalism, the main interface program logs this occurrence
in a file. This file records the number of these instances against the date and hour in
which they took place. This file can be downloaded from the web site and used to
determine trends. Because it is to show trends it is necessary that this information
can be plotted easily against a time scale. The best way to achieve this is to create the
file in a format that can be viewed by a spreadsheet program.
The format which was deemed most appropriate, and was therefore implemented, was
that used by the Microsoft program Excel. There are two reasons this format was
chosen. The first reason is the simple layout of the file interior. The fields of the
spreadsheet are separated by semi-colons and hard return delimiters. This not only
makes the file compatible with the Microsoft Excel program, but means it can be
viewed easily in a text editor, and is easily adaptable to other spreadsheet programs.
The second reason this for this decision was, that of all spreadsheet programs,
Microsoft Excel has the largest installation base.
Chapter 6
Results
The performance of the system is gauged by examining the initial aims of the thesis,
and the system specifications and comparing this with the actual design
implementation. In other words, the actual finished product must match the goals and
requirements set down at the beginning of the thesis project. For the sake of
simplicity, a summary of the aims of the thesis, and the subsequent requirements and
design specifications, will be given. Interspersed throughout this summary is
discussion which determines whether or not these goals have been met. In this
manner the performance of the system will be described, both at a high and low level.
6.1 High Level System
This aim of this thesis project was to produce a device to be installed in a vending
machine, which would be able to remotely show the status of this machine by way of
the Internet. The device was to be able to report the stock levels of the vending
machine, the machine's internal temperature, the relative temperatures of the
merchandise it houses, and possible incidents of vandalism.
The requirements of this system are listed below:
the status of the vending machine must be able to be viewed in any recent
graphical web browser.
email reports are to be sent from the machine to its owner/operator to
notify that the machine requires attention (i.e. low stock warning,
vandalism reports)
sales data and vandalism attempts are to logged and stored as a file
capable of being be downloaded from the machines web site.
the cost of the system as a whole is to be kept relatively low.
This system was tested with several different versions of both the Microsoft Internet
Explorer web browser and the Netscape Navigator web browser. In every instance
examined, the status information of the machine could be viewed without problems.
Since these applications make up the vast majority of graphical web browsers in use
the system requirement stating that status information must be viewable in any recent
graphical web browser was completely.
As mentioned earlier in this Thesis document the system has the capacity to record
and store any changes in status (with respect to a time variable), to a file. This log
file was downloaded and opened using the Microsoft Excel spreadsheet program.
The hardware used in the design was all very easy to obtain and the processor that
was chosen has been available for a very long time. All of the other hardware parts
used were generic parts which can be replaced easily. Both the operating system and
the web server application running on the processor are free-liscence software.
Taking into account all of the parts used in the design it was found that the system
could be produced for a cost of less than $200 per unit. This cost, in comparison to
that of the vending machine (i.e. in excess of $4000), is very inexpensive, and
therefore conforms to the thesis aims.
6.2 Hardware Sub-system
The main requirement of the hardware design is that it should allow room for future
updates in the system. Due to the PC architecture upon which the hardware
implementation is built on this is achieved easily. It is worth noting that for a time
the Microsoft DOS operating system was running on the system's hardware (during
the very early stages of the project), and when the decision was made to use Linux
OS, the change was made with very little effort.
The specifications for the vending machine sensors were as follows:
Stock Level Sensors :
to be measured as a coupling of refill and dispense signals
Vandalism Sensor:
generates a pulse whenever the machine sustains impact of a
measurable level, or when the machine is tilted
Internal Temperature Sensor:
is to output temperature using just one data line by streaming
Upon inspection it was found that all of the specifications given for the vending
machine sensors were met. It is worth noting that the pulse generated by the
vandalism sensor, as it was implemented, was not of a fixed duration, but was
determined directly by the level of action it received (i.e. simple tilt switch
arrangement).
6.3 Software Sub-system
As mentioned several times, the software design essentially consists of the major
parts; the operating system, the web server and interface software.
The operating system used within the software design of this thesis project was to be
able to be run multiple tasks concurrently and allow users to login to it remotely.
With respect to multi-tasking requirement of the operating system, Linux is more than
capable. This is evidenced by the many separate programs and applications which all
run together (i.e. web server software, CCI-scripts, C program, etc.). Much of the
software development done for this project was done remotely, by 'telneting' to the
location of the hardware, and logging into a terminal, thus gaining access to the
system. In this way it can be seen that this requirement has been met.
The web server application to be used in the system, was to be able to serve pages at a
fast rate, while still providing a high level of security. In addition to this the web
server was to be able to be updated easily (i.e. in the event of later versions of HTTP
etc.). As detailed earlier in this document, the Apache web server application meets
all of these specifications.
The specifications of the interface software's tasks are given in point form below:
creates the HTML documents based on sensor input
logs changes in the vending machines status to a file
compose and send email reports when machine requires attention
All of these aspects of the interface software were tested and found to work as
specified.
Chapter 7
Design Review
While the results of the project describe whether or not the original aims were met, it
does not make mention of any of the future developments which could be made to the
system. In addition to this no mention has been given to how well the author
performed in the role of a design engineer. In order to describe the thesis experience
as a whole it is necessary that both of these issues be addressed. This chapter does
this and in doing so gives a review of the design aspects of this thesis
7.1 Future Developments
While the system that has been designed and built for this thesis project meets all of
the objectives identified initially, the possibilities for the expansion and modification
of this design are vast. By using a PC as the major hardware component of the
design, adding extra features to the system at a later date is quite simple. The design,
as it is, is very modular. This allows any necessary hardware and software design
modifications, to suit different classes of vending machines, to be made very easily.
After this has been done it is simply a matter of replacing these components of the
system.
Apart from the modifications needed to use this design with vending machines other
than the Coke machine used in this project, there are many ways in which the overall
system could be enhanced.
7.1.1 Control Features
The most obvious enhancement which could be made, would be to add control
features to the design. This would be easily achieved by utilising the unused serial
port on the PC I/O card. The control features could be added to the system without
affecting the overall modularity and flexibility of the design.
This is readily achievable by writing a generic software control module to send
commands, via the serial port, to a hardware control interface. Some examples of the
system control commands, which could be issued by the control module, would be
the ability to change the price of products, change the refrigeration settings of the
machine and to dispense products remotely. Since the inner workings of each type of
vending machine can vary markedly, a unique hardware control interface would need
to be developed accordingly. The function of this interface would be to translate the
commands issued by the PC, into control signals that could be understood by a
particular vending machine.
By designing the control system in this way, most of the system design would remain
independent of individual vending machines and would therefore stay true to the
original aims of this thesis. By adding control capabilities, the functionality of the
system more than doubles.
7.1.2 Hardware Improvements
A very sensible suggestion concerning the hardware external to the PC, would be to
incorporate these designs onto a single PC ISA card. In addition to making the
design much neater and more compact, this would free up both the parallel port and
the serial port, as the hardware design would be able to communicate with software
by way of the PC bus.
The hardware design used in this thesis project could also be improved by designing a
cut-back version of the PC. This would significantly reduce the amount of space
taken up inside the vending machine by the device.
7.1.3 Software Improvements
At the beginning of this project it was not known exactly what features of the Linux
operating system would be needed for the development of the system. For this reason
a complete installation of the OS was performed. As many of the features of this OS
are not crucial to the final design of the system (eg. there is no need for any graphical
capabilities), there is no need to perform a complete installation. By carefully
examining what software is needed and what is not, the memory requirements of the
OS can be minimised.
Since the ability to expand both the hardware and software aspects of the system
design is of utmost importance, it is recommended that the installation take into
account future designs (i.e. consideration should be given as to what software might
be needed for later designs)
7.2 Personal Performance
This section of the design review critiques the author's performance in the role of a
design engineer.
One of the foremost requirements of a design engineer is the capacity to meet all of
the specifications for a given product, while achieving an efficient solution. This
involves examining all of the available alternatives during each step of the product
implementation, and weighing the merits of these possible choices against each other.
This objective was remembered and applied throughout the duration of the entire
thesis project, and no design decision was made before carefully considering the
options at hand. By doing this it was possible to develop contingency plans to
combat any unforseen difficulties which may become obvious upon the choice of a
particular implementation (i.e. certain parts cannot be delivered etc.).
While the aims of this thesis were met, it is worth noting that the development of the
system could have taken a shorter amount of time if some design decisions were not
initally pursued. This can be put down to limited experience, and would not occur to
the same extent were a project of a similar magnitude now commenced.
Although this thesis project was done by just one person, as opposed to a team of
engineers, it is important to recognise that the role of a design engineer requires a
certain level of 'people skills'. In particular the ability to communicate effectively
with others is of great importance. Furthermore it is necessary that these 'people
skills' extend beyond the engineering environment. This is due to the fact that it is
often necessary to correspond with people who are not engineers (eg. human relations
managers, reception personnel, sales staff, etc.)
A particularly good example of where such skills were needed/used, for this thesis
project was in procuring a vending machine. This process required a great amount of
communication with customer service representatives, numerous technical staff and a
project manager. This correspondance took both verbal and written form (i.e. phone
calls, personal meetings, and letter writing).
In summation, most of the aspects required to be a good design engineer have been
met during the course of this thesis project. The thesis provided a very good practical
way of learning what skills are required in design engineering and how they are
applied in a real situation.
Chapter 8
Conclusion
As it has been shown by the results of this thesis, a generic device to interface
vending machines to the Internet has many advantages. The list of ways such a
device can be used in conjunction with the vending machine, would continue to grow
as this technology became more used within the vending industry.
By using a PC architecture the possibilities for both hardware and software
enhancements, are greatly increased. The use of an operating system that allows
remote login means that any software changes (which still use an unchanged
hardware design) can be effected immediately.
On a more personal not this thesis gave me the opportunity to experience just what a
design project is like, and how very important communication skills are.
References
[1] Luyer, D., et al., The University Computer Club: Coke Machine,
http://www.ucc.gu.uwa.edu.au/services/drink.ucc, Last Accessed 15/9/99
[2] Forrester, J., Wade, M., The SACM Coke Club,
http://www.cs.wisc.edu/~sacmuse/coke/coke.html, Last Accessed 2/9/1999
[3] Jonke, M., et al., The Vending Machines at DIKU, http://amigos12.diku.dk,
Last accessed 10/8/1999
[4] Haas, P., Paul Haas's Web Server, http://www.hamjudo.com, Last accessed
24/9/1999
[5] Dallas Semiconductor Inc., DS1620 Digital Thermometer and Thermostat
Data Sheet, Available as a PDF from,
http://www.dalsemi.com/DocControl/PDFs/1620.pdf, Last accessed 17/8/99
[6] Peacock, C., Interfacing the Standard Parallel Port,
http://www.senet.com.au/~cpeacock, Last accessed 10/9/1999
[7] The Apache Software Foundation, Apache HTTP Server project,
http://www.apache.org/httpd.html, Last accessed 15/10/1999
[8] Berners-Lee, I, et al., 1996, RFC 1945: Hypertext Transfer Protocol -
HTTP/1.0, Network Working Group,
http://ds.internic.net/ds/dspg0intdoc.html, Last accessed 26/6/1999
[9] Fischer, W.W., Is Push Technology Really Dead?, Last accessed 13/10/1999
[10] Hedley, J., Jon's CGI-Scape, http://www.cgi.tj, Last accessed 18/10/1999
Appendix A
Printed Circuit Board Artwork
Parallel Port Interface: Top Layer Design
Parallel Port Interface: Bottom Layer Design
Appendix B
Altera Design
Project Information
c:\windows\desktop\nathan\maxplus\vendref4.rpt
MAX+plus II Compiler Report File
Version 9.01 07/30/98
Compiled: 09/30/99 12:56:07
Copyright (C) 1988-1998 Altera Corporation
Any megafunction design, and related net list (encrypted or
decrypted),
support information, device programming or simulation file, and any
other
associated documentation or information provided by Altera or a
partner
under Altera's Megafunction Partnership Program may be used only to
program PLD devices (but not masked PLD devices) from Altera. Any
other
use of such megafunction design, net list, support information,
device
programming or simulation file, or any other related documentation
or
information is prohibited for any other purpose, including, but not
limited to modification, reverse engineering, de-compiling, or use
with
any other silicon devices, unless such use is explicitly licensed
under
a separate agreement with Altera or a megafunction partner. Title
to
the intellectual property, including patents, copyrights,
trademarks,
trade secrets, or maskworks, embodied in any such megafunction
design,
net list, support information, device programming or simulation
file, or
any other related documentation or information provided by Altera or
a
megafunction partner, remains with Altera, the megafunction partner,
or
their respective licensors. No other licenses, including any
licenses
needed under any third party's intellectual property, are provided
herein.
***** Project compilation was successful
** DEVICE SUMMARY **
Chip/ Input Output Bidir Shareable
POF Device Pins Pins Pins LCs Expanders
% Utilized
vendrefl EPM7032SLC44-10 19 6 0 14 0
43 %
User Pins: 19 6 0
Device-Specific Information:
vendrefl
***** Logic for device 'vendrefl' compiled without errors.
Device: EPM7032SLC44-10
Device Options:
Turbo Bit = ON
Security Bit = OFF
Enable JTAG Support = ON
User Code = ffff
R R R
E E E
F F F D D
I I I I I
L L L S S
L L L V G G G G G P P
_ _ _ C N N N N N _ _
3 2 1 C D D D D D 5 4
-----------------------------------_
/ 6 5 4 3 2 1 44 43 42 41 40 |
#TDI | 7 39 | REFILL
REFILL_4 | 8 38 | #TDO
REFILL_5 | 9 37 | DISP_3
GND | 10 36 | DISP_2
REFILL_6 | 11 35 | VCC
REFILL_7 | 12 EPM7032SLC44-10 34 | COL_ID_1
#TMS | 13 33 | VANDFLAG
RESET | 14 32 | #TCK
VCC | 15 31 | COL_ID_2
VANDALSM | 16 30 | GND
VANDREST | 17 29 | DISP_0
|_ 18 19 20 21 22 23 24 25 26 27 28 _|
------------------------------------
R D D D G V R R D C R
E I I I N C E E I O E
F S S S D C S S S L S
I P P P E E P _ E
L _ _ _ R R E I R
L 7 1 6 V V N D V
_ E E S _ E
0 D D E 0 D
N.C. = Not Connected.
VCC = Dedicated power pin, which MUST be connected to VCC.
GND = Dedicated ground pin or unused dedicated input, which MUST be
connected to GND.
RESERVED = Unused I/O pin, which MUST be left unconnected.
^ = Dedicated configuration pin.
+ = Reserved configuration pin, which is tri-stated during user
mode.
* = Reserved configuration pin, which drives out in user mode.
PDn = Power Down pin.
@ = Special-purpose pin.
# = JTAG Boundary-Scan Testing/In-System Programming or
Configuration Pin. The JTAG inputs (TMS, TCK, TDI) should be tied to
VCC when not in use.
& = JTAG pin used for I/O. When used as user I/O, JTAG pins must be
kept stable before and during configuration. JTAG pin stability
prevents accidental loading of JTAG instructions.
vendrefl
** RESOURCE USAGE **
Shareable
External
Logic Array Block Logic Cells I/O Pins Expanders
Interconnect
A: LC1 - LC16 0/16( 0%) 16/16(100%) 0/16( 0%) 0/36(
0%)
B: LC17 - LC32 14/16( 87%) 13/16( 81%) 0/16( 0%) 29/36(
80%)
Total dedicated input pins used: 0/4 ( 0%)
Total I/O pins used: 29/32 ( 90%)
Total logic cells used: 14/32 ( 43%)
Total shareable expanders used: 0/32 ( 0%)
Total Turbo logic cells used: 14/32 ( 43%)
Total shareable expanders not available (n/a): 0/32 ( 0%)
Average fan-in: 4.64
Total fan-in: 65
Total input pins required: 19
Total fast input logic cells required: 0
Total output pins required: 6
Total bidirectional pins required: 0
Total reserved pins required 4
Total logic cells required: 14
Total flipflops required: 0
Total product terms required: 24
Total logic cells lending parallel expanders: 0
Total shareable expanders in database: 0
Synthesized logic cells: 0/ 32 ( 0%)
vendrefl
** INPUTS **
Shareable
Expanders Fan-In
Fan-Out
Pin LC LAB Primitive Code Total Shared n/a INP FBK OUT
FBK Name
29 (27) (B) INPUT 0 0 0 0 0
0 1 DISP_0
20 (15) (A) INPUT 0 0 0 0 0
0 1 DISP_1
36 (22) (B) INPUT 0 0 0 0 0
0 1 DISP_2
37 (21) (B) INPUT 0 0 0 0 0
0 1 DISP_3
40 (18) (B) INPUT 0 0 0 0 0
0 1 DISP_4
41 (17) (B) INPUT 0 0 0 0 0
0 1 DISP_5
21 (16) (A) INPUT 0 0 0 0 0
0 1 DISP_6
19 (14) (A) INPUT 0 0 0 0 0
0 1 DISP_7
18 (13) (A) INPUT 0 0 0 0 0
1 1 REFILL_0
4 (1) (A) INPUT 0 0 0 0 0
1 1 REFILL_1
5 (2) (A) INPUT 0 0 0 0 0
1 1 REFILL_2
6 (3) (A) INPUT 0 0 0 0 0
1 1 REFILL_3
8 (5) (A) INPUT 0 0 0 0 0
1 1 REFILL_4
9 (6) (A) INPUT 0 0 0 0 0
1 1 REFILL_5
11 (7) (A) INPUT 0 0 0 0 0
1 1 REFILL_6
12 (8) (A) INPUT 0 0 0 0 0
1 1 REFILL_7
14 (10) (A) INPUT 0 0 0 0 0
1 8 RESET
16 (11) (A) INPUT 0 0 0 0 0
1 0 VANDALISM
17 (12) (A) INPUT 0 0 0 0 0
1 0 VANDRESET
Code:
s = Synthesized pin or logic cell
t = Turbo logic cell
+ = Synchronous flipflop
/ = Slow slew-rate output
! = NOT gate push-back
r = Fitter-inserted logic cell
vendrefl
** OUTPUTS **
Shareable
Expanders Fan-In
Fan-Out
FBK Name
27 29 B OUTPUT t 0 0 0 0 4
0 0 COL_ID_0
34 23 B OUTPUT t 0 0 0 0 4
0 0 COL_ID_1
31 26 B OUTPUT t 0 0 0 0 4
0 0 COL_ID_2
26 30 B OUTPUT t 0 0 0 0 8
0 0 DISPENSE
39 19 B OUTPUT t 0 0 0 9 1
1 0 REFILL
33 24 B OUTPUT t 0 0 0 2 1
1 0 VANDFLAG
Code:
vendrefl
** BURIED LOGIC **
Shareable
Expanders Fan-In
Fan-Out
FBK Name
(28) 28 B LCELL t 0 0 0 3 1
4 1 :56
(32) 25 B LCELL t 0 0 0 3 1
3 1 :68
(36) 22 B LCELL t 0 0 0 3 1
2 1 :90
(37) 21 B LCELL t 0 0 0 3 1
3 1 :91
(41) 17 B LCELL t 0 0 0 3 1
1 1 :98
(29) 27 B LCELL t 0 0 0 3 1
2 1 :99
(38) 20 B LCELL t 0 0 0 3 1
2 1 :100
(40) 18 B LCELL t 0 0 0 3 1
3 1 :101
Code:
vendrefl
** LOGIC CELL INTERCONNECTIONS **
Logic Array Block 'B':
Logic cells placed in LAB 'B'
+--------------------------- LC29 COL_ID_0
| +------------------------- LC23 COL_ID_1
| | +----------------------- LC26 COL_ID_2
| | | +--------------------- LC30 DISPENSE
| | | | +------------------- LC19 REFILL
| | | | | +----------------- LC24 VANDFLAG
| | | | | | +--------------- LC28 :56
| | | | | | | +------------- LC25 :68
| | | | | | | | +----------- LC22 :90
| | | | | | | | | +--------- LC21 :91
| | | | | | | | | | +------- LC17 :98
| | | | | | | | | | | +----- LC27 :99
| | | | | | | | | | | | +--- LC20 :100
| | | | | | | | | | | | | +- LC18 :101
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | Other LABs fed by signals
| | | | | | | | | | | | | | that feed LAB 'B'
LC | | | | | | | | | | | | | | | A B | Logic cells that
feed LAB 'B':
LC19 -> - - - - * - - - - - - - - - | - * | <-- REFILL
LC24 -> - - - - - * - - - - - - - - | - * | <-- VANDFLAG
LC28 -> * * * * - - * - - - - - - - | - * | <-- :56
LC25 -> * - * * - - - * - - - - - - | - * | <-- :68
LC22 -> * - - * - - - - * - - - - - | - * | <-- :90
LC21 -> * * - * - - - - - * - - - - | - * | <-- :91
LC17 -> - - - * - - - - - - * - - - | - * | <-- :98
LC27 -> - * - * - - - - - - - * - - | - * | <-- :99
LC20 -> - - * * - - - - - - - - * - | - * | <-- :100
LC18 -> - * * * - - - - - - - - - * | - * | <-- :101
Pin
29 -> - - - - - - - - - - * - - - | - * | <-- DISP_0
20 -> - - - - - - - - * - - - - - | - * | <-- DISP_1
36 -> - - - - - - - - - - - * - - | - * | <-- DISP_2
37 -> - - - - - - - - - * - - - - | - * | <-- DISP_3
40 -> - - - - - - - - - - - - * - | - * | <-- DISP_4
41 -> - - - - - - - * - - - - - - | - * | <-- DISP_5
21 -> - - - - - - - - - - - - - * | - * | <-- DISP_6
19 -> - - - - - - * - - - - - - - | - * | <-- DISP_7
18 -> - - - - * - - - - - * - - - | - * | <-- REFILL_0
4 -> - - - - * - - - * - - - - - | - * | <-- REFILL_1
5 -> - - - - * - - - - - - * - - | - * | <-- REFILL_2
6 -> - - - - * - - - - * - - - - | - * | <-- REFILL_3
8 -> - - - - * - - - - - - - * - | - * | <-- REFILL_4
9 -> - - - - * - - * - - - - - - | - * | <-- REFILL_5
11 -> - - - - * - - - - - - - - * | - * | <-- REFILL_6
12 -> - - - - * - * - - - - - - - | - * | <-- REFILL_7
14 -> - - - - * - * * * * * * * * | - * | <-- RESET
16 -> - - - - - * - - - - - - - - | - * | <-- VANDALISM
17 -> - - - - - * - - - - - - - - | - * | <-- VANDRESET
* = The logic cell or pin is an input to the logic cell (or LAB)
through the PIA.
- = The logic cell or pin is not an input to the logic cell (or
LAB).
vendrefl
** EQUATIONS **
DISP_0 : INPUT;
DISP_1 : INPUT;
DISP_2 : INPUT;
DISP_3 : INPUT;
DISP_4 : INPUT;
DISP_5 : INPUT;
DISP_6 : INPUT;
DISP_7 : INPUT;
REFILL_0 : INPUT;
REFILL_1 : INPUT;
REFILL_2 : INPUT;
REFILL_3 : INPUT;
REFILL_4 : INPUT;
REFILL_5 : INPUT;
REFILL_6 : INPUT;
REFILL_7 : INPUT;
RESET : INPUT;
VANDALISM : INPUT;
VANDRESET : INPUT;
-- Node name is 'COL_ID_0'
-- Equation name is 'COL_ID_0', location is LC029, type is output.
COL_ID_0 = LCELL( _EQ001 $ VCC);
_EQ001 = !_LC021 & !_LC022 & !_LC025 & !_LC028;
_EQ002 = !_LC018 & !_LC021 & !_LC027 & !_LC028;
_EQ003 = !_LC018 & !_LC020 & !_LC025 & !_LC028;
-- Node name is 'DISPENSE'
-- Equation name is 'DISPENSE', location is LC030, type is output.
DISPENSE = LCELL( _EQ004 $ VCC);
_EQ004 = !_LC017 & !_LC018 & !_LC020 & !_LC021 & !_LC022 & !_LC025
&
!_LC027 & !_LC028;
-- Node name is 'REFILL' = ':115'
-- Equation name is 'REFILL', type is output
REFILL = LCELL( _EQ005 $ VCC);
_EQ005 = !REFILL & !REFILL_0 & !REFILL_1 & !REFILL_2 & !REFILL_3 &
!REFILL_4 & !REFILL_5 & !REFILL_6 & !REFILL_7
# RESET;
-- Node name is 'VANDFLAG' = ':112'
-- Equation name is 'VANDFLAG', type is output
VANDFLAG = LCELL( _EQ006 $ GND);
_EQ006 = VANDALISM & !VANDRESET
# VANDFLAG & !VANDRESET;
-- Node name is ':56'
-- Equation name is '_LC028', type is buried
_LC028 = LCELL( _EQ007 $ VCC);
_EQ007 = !DISP_7 & !_LC028 & !REFILL_7
# RESET;
_EQ008 = !DISP_5 & !_LC025 & !REFILL_5
# RESET;
_EQ009 = !DISP_1 & !_LC022 & !REFILL_1
# RESET;
_EQ010 = !DISP_3 & !_LC021 & !REFILL_3
# RESET;
_EQ011 = !DISP_0 & !_LC017 & !REFILL_0
# RESET;
_EQ012 = !DISP_2 & !_LC027 & !REFILL_2
# RESET;
_EQ013 = !DISP_4 & !_LC020 & !REFILL_4
# RESET;
_EQ014 = !DISP_6 & !_LC018 & !REFILL_6
# RESET;
-- Shareable expanders that are duplicated in multiple LABs:
-- (none)
Project Information
** COMPILATION SETTINGS & TIMES **
Processing Menu Commands
------------------------
Design Doctor = off
Logic Synthesis:
Synthesis Type Used = Standard
Default Synthesis Style = NORMAL
Logic option settings in 'NORMAL' style for 'MAX7000S' family
DECOMPOSE_GATES = on
DUPLICATE_LOGIC_EXTRACTION = on
MINIMIZATION = full
MULTI_LEVEL_FACTORING = on
NOT_GATE_PUSH_BACK = on
PARALLEL_EXPANDERS = off
REDUCE_LOGIC = on
REFACTORIZATION = on
REGISTER_OPTIMIZATION = on
RESYNTHESIZE_NETWORK = on
SLOW_SLEW_RATE = off
SOFT_BUFFER_INSERTION = on
SUBFACTOR_EXTRACTION = on
TURBO_BIT = on
XOR_SYNTHESIS = on
IGNORE_SOFT_BUFFERS = off
USE_LPM_FOR_AHDL_OPERATORS = off
Other logic synthesis settings:
Automatic Global Clock = on
Automatic Global Clear = on
Automatic Global Preset = on
Automatic Global Output Enable = on
Automatic Fast I/O = off
Automatic Register Packing = off
Automatic Open-Drain Pins = on
Automatic Implement in EAB = off
One-Hot State Machine Encoding = off
Optimize = 5
Default Timing Specifications: None
Cut All Bidir Feedback Timing Paths = on
Cut All Clear & Preset Timing Paths = on
Ignore Timing Assignments = on
Functional SNF Extractor = off
Linked SNF Extractor = off
Timing SNF Extractor = on
Optimize Timing SNF = off
Generate AHDL TDO File = off
Fitter Settings = NORMAL
Smart Recompile = off
Total Recompile = off
Interfaces Menu Commands
------------------------
EDIF Netlist Writer = off
Verilog Netlist Writer = off
VHDL Netlist Writer = off
Compilation Times
-----------------
Compiler Netlist Extractor 00:00:03
Database Builder 00:00:00
Logic Synthesizer 00:00:04
Partitioner 00:00:02
Fitter 00:00:03
Timing SNF Extractor 00:00:01
Assembler 00:00:00
-------------------------- --------
Total Time 00:00:13
Memory Allocated
-----------------
Peak memory allocated during compilation = 2,745K
Appendix C
Code Listings:
HTML code
CGI-Scripts
C programs
HTML code:
Index.html:
<HTML>
<HEAD>
<Title> COKE.NET | 1999 Thesis Project of Nathan Roche</TITLE>
</HEAD>
<FRAMESET ROWS="215, *, 150">
<FRAME SRC="title.html">
<FRAME SRC="temp_stat.html">
<FRAME SRC="machcond.html">
<NOFRAMES> ONLY FRAME CAPABLE BROWSERS CANE SEE THIS PAGE
</NOFRAMES>
</FRAMESET>
</HTML>
temp_stat.html:
<HTML>
<HEAD>
<Title> COKE.NET | 1999 Thesis Project of Nathan Roche</TITLE>
</HEAD>
<FRAMESET COLS="250, *">
<FRAME SRC="tempy.html">
<FRAME SRC="stat.html">
<NOFRAMES> ONLY FRAME CAPABLE BROWSERS CANE SEE THIS PAGE
</NOFRAMES>
</FRAMESET>
</HTML>
CGI-Script
Vandreset.cgi:
#!/usr/bin/perl
# Name: vandreset.cgi
#
# Purpose: To change the contents of a file when a vandalism reset
# button appears on screen (only during vandaism), so that a
# C program might read this and update the relevant HTML
# document.
#
# Written by: Nathan Roche
#
# Last Modified: 7 September 1999
#
@valid_servers = ('coke.pc.elec.uq.edu.au');
&parseform;
$logpath = '/home/httpd/html/vandreset.txt';
if ($logpath)
{
unless (-e $logpath) {error("$logpath does not exist.")}
unless (-W $logpath) {error("$logpath is not world writable.")}
$line = "1";
open(FILE, ">>$logpath") or error("Could not open $logpath for append:$!");
flock(FILE,2) or error("Could not lock file $logpath: $!");
print FILE $line;
close(FILE);
}
if ($FORM{'HTTP_REFERER'} and @valid_servers)
{
$match = 0;
foreach $server (@valid_servers)
{if ($FORM{'HTTP_REFERER'} =~ m|$http.*://$server|) {$match++}}
unless ($match)
{
print "Content-Type: text/html\n\n";
print "$FORM{'HTTP_REFERER'} is not authorised to use this script.";
exit(0)
}
}
unless ($FORM{'url'})
{
print "Content-Type: text/html\n\n";
print "No URL was specified. Please check your HTML.";
exit(0)
}
print "Location: $FORM{'url'}\n\n";
sub parseform
{
if ($ENV{'REQUEST_METHOD'} eq 'GET') {@pairs = split(/&/, $ENV{'QUERY_STRING'});}
elsif ($ENV{'REQUEST_METHOD'} eq 'POST')
{
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
}
else {out('Bad or Unknown Request Method')}
foreach $pair (@pairs)
{
local($name, $value) = split(/=/, $pair);
$name =~ tr/+/ /;
$name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$value =~ s///g;
$value =~ tr/</&lt\;/;
$value =~ tr/>/&gt\;/;
$FORM{$name} = $value;
}
}
C programs
main.c
/*
* Name: main.c
*
* Purpose: This file is the main program that runs continually
* in order to gather information from sensors and interpret
* it to a form that can be understood by the web server.
* It assumes that the vending machine is empty when the
* program starts
*
* Written By: Nathan Roche
*
* Last Modified: 8/10/99
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <asm/io.h>
#include <time.h>
#include "htmlbuilder.c"
#include "tempcode.c"
#define DATAPORT 0x378
#define STATUSPORT 0x379
#define CONTROLPORT 0x37A
#define STATREPORTHTML "statrept.html" /* for updating stock figures */
#define MACHCONDHTML "machcond.html" /* for updating machine condition */
#define P_DATA 0xFF
#define MAXCOKES 16
#define NUMBER_COLUMNS 8
#define LOWSTOCKLEVEL 3
/* masks */
/* Data port masks */
#define VANDRESET 0x02
#define RESET 0x01
#define ALLRESET 0x03
#define NORESET 0x00
/* control port masks */
/* #define TEMP_D 0x08*/
#define COL_ID 0x07
/* Status port masks */
#define REFMASK 0x80
#define DISPMASK 0x40
#define VANDMASK 0x20
/* prototypes */
int template1(int value[NUMBER_COLUMNS], char *filename);
int template2(int vandswitch, char *filename);
int template3(char *strtemp, char *filename);
int temp_routine();
void disp_routine();
void vand_routine();
void email(int mesg);
void makelog(int vand, int column_no);
float temperature();
/* GLOBAL VARIABLES */
int bottles_left[NUMBER_COLUMNs]);
unsigned long refill_time[NUMBER_COLUMNS];
int refill, dispense, vandflag;
int control, status;
int column;
int i;
float temp;
time_t timevar;
struct tm *timey;
struct log_row {
char date[10];
int hour;
int vandalism;
int column[NUMBER_COLUMNS];
} log_data;
/*
* The main function simply initialises all of the data structures, and
* sensor readings, and then runs in a loop until activity is sensed.
* It then deals with this activity (by calling another function) and
* returns to the loop.
*/
int main(void)
{
int i;
FILE *fp;
char *strtemp;
/* initialise variables*/
/* gives control of the printer port to the program */
if (ioperm(DATAPORT, 3, 1)) {
perror("ioperm");
exit(1);
}
usleep(100000);
/* pulse ALTERA reset and vandreset */
outb(NORESET, DATAPORT);
usleep(100000);
outb(ALLRESET, DATAPORT);
usleep(100000);
usleep(100000);
/*
* Enable control bit 2 as an input
*/
outb(4, CONTROLPORT);
/*
* Sleep for a while (100 ms)
*/
usleep(100000);
/* columns full */
for (i = 0; i < NUMBER_COLUMNS; i++) {
bottles_left[i] = MAXCOKES;
}
/*
* Initialise HTML documents
*/
template1(bottles_left, STATREPORTHTML);
template2(0, MACHCONDHTML);
/* Initialise Log variables */
time(&timevar);
timey = localtime(&timevar);
sprintf(log_data.date, "%02d/%02d/%02d", timey->tm_mday,
timey->tm_mon + 1, timey->tm_year);
log_data.hour = timey->tm_hour;
log_data.vandalism = 0;
log_data.column[i] = 0;
}
/*
* setup log file
*/
if (fp = fopen("prelogdata.txt", "w")) {
fprintf(fp, "DATE HOUR VANDALISM COLUMN0 COLUMN1 COLUMN2 ");
fprintf(fp, "COLUMN3 COLUMN4 COLUMN5 COLUMN6 COLUMN7;\n");
}
fclose(fp);
for (;;) {
/* Get access to the ports */
status = inb(STATUSPORT);
refill = !((status & REFMASK) >> 7);
dispense = (status & DISPMASK) >> 6;
vandflag = (status & VANDMASK) >> 5;
printf("refill= %d dispense= %d vandflag= %d\n", refill,
dispense, vandflag);
/* do temperature read from DS1620 */
temp = temperature();
sprintf(strtemp, "%5.1f C", temp);
template3(strtemp, "tempy.html");
if (dispense) {
disp_routine();
}
if (vandflag)
vand_routine();
usleep(100000);
/*
* We don't need the ports anymore
*/
}
if (ioperm(DATAPORT, 3, 0)) {
perror("ioperm");
exit(1);
}
usleep(100000);
exit(0);
}
/*
* This routine is entered when a dispense signal is sensed.
* After entering this loop it is determined whether it is a refill or
* dispense operation which is to occur. The stock numbers are then
* changed accordingly and HTML files are updated
*/
void disp_routine()
{
int j;
/*
* Read from control port (BASE+2) and
* identify the active column
*/
control = inb(CONTROLPORT);
column = (control & COL_ID) ^ 0x03;
if (refill == 0) {
if (column && (bottles_left[column] > 0))
bottles_left[column]--;
/*
* update the log file
*/
makelog(0, column);
if (bottles_left[column] == LOWSTOCKLEVEL)
/*
* send low stock report email
*/
email(1);
} else
bottles_left[column] = MAXCOKES;
template1(bottles_left, STATREPORTHTML);
printf("Column Number: %d \n", column);
printf("Bottles left: %d\n\n", bottles_left[column]);
outb(RESET, DATAPORT);
usleep(100000);
usleep(100000);
/*
* Defines wait time until HTML regenerates
*/
usleep(10000);
}
/*
* This routine is entered when vandalism is detected.
*/
void vand_routine()
{
FILE *fp;
/*
* send vandalism report email
*/
email(0);
/*
* update the log file
*/
makelog(1, 0);
if (fp = fopen("vandreset.txt", "r")) {
/* if VAND RESET from web page */
if (fgetc(fp) != EOF) {
printf("in vand reset section\n");
outb(VANDRESET, DATAPORT);
usleep(1000);
usleep(1000);
printf("dispense: %d \n", dispense);
printf("vandflag: %d \n", vandflag);
printf("refill: %d \n\n", refill);
fclose(fp);
fopen("vandreset.txt", "w");
}
}
fclose(fp);
template2(vandflag, MACHCONDHTML);
usleep(300000);
}
/*
* This function sends a particular email message based on the message
* variable. This is done by writing the message to a file, and then
* parsing this file through the mail server.
*/
void email(int mesg)
{
FILE *fp;
fp = fopen("email_msg", "w");
if (mesg == 0) {
/* create message and write it to file */
fprintf(fp, "VANDALISM REPORT\n");
fprintf(fp, "***********************************\n\n");
fprintf(fp, "LOCATION: Thesis Labs, UQ\n\n");
fprintf(fp, "MESSAGE:\n");
fprintf(fp, " Please notify the relevant\n");
fprintf(fp, " authorities of this action.\n");
fprintf(fp, " Please inspect this machine\n");
fprintf(fp, " for any damage\n");
fprintf(fp, "***********************************\n");
} else if (mesg == 1) {
fprintf(fp, "LOW STOCK WARNING\n");
fprintf(fp, "***********************************\n\n");
fprintf(fp, "LOCATION: Thesis Labs, UQ\n\n");
fprintf(fp, "MESSAGE:\n");
fprintf(fp, " Low stock has been sensed.\n");
fprintf(fp, " Please restock the machine.\n\n");
fprintf(fp, "***********************************\n");
}
fclose(fp);
system("mail s341663@student.uq.edu.au < email_msg");
}
/*
* This function creates a log file of all changes in status in .xls file
* format
*/
void makelog(int vand, int column_no)
{
FILE *fp;
/* calculate time from system clock */
time(&timevar);
timey = localtime(&timevar);
if (timey->tm_hour != log_data.hour) {
/*
* write to log data to prebuild xls file;
*/
if (fp = fopen("prelogdata.txt", "a")) {
fprintf(fp, "%s %d %d",
log_data.date, log_data.hour, log_data.vandalism);
fprintf(fp, "%d ", log_data.column[i]);
}
fprintf(fp, "\n");
}
fclose(fp);
/* reinit the log_data struct */
log_data.column[i] = 0;
}
log_data.vandalism = 0;
}
/* write details of status change to the structure */
sprintf(log_data.date, "%d/%d/%d",
timey->tm_mday, timey->tm_mon + 1, timey->tm_year);
log_data.hour = timey->tm_hour;
if (vand)
log_data.vandalism++;
else
log_data.column[column_no]++;
/* write the old file data to the newly created xls file*/
system("cat prelogdata.txt > cokelog.xls");
/* change read permissions */
system("chmod 744 cokelog.xls");
fp = fopen("cokelog.xls", "a");
fprintf(fp, "%s %d ", log_data.date, log_data.vandalism);
fprintf(fp, "%d ", log_data.column[i]);
}
fprintf(fp, "\n");
fclose(fp);
}
tempcode.c
/*
* Name: tempcode.c
*
* Purpose: The purpose of this program is to recieve and interpret
* temperature information from the DS1620 temperature sensor
*
* Written by: Nathan Roche
*
* Last Modified:8/10/99
*
*/
#include <stdio.h>
#include <unistd.h>
#include <asm/io.h>
/* declare base address and macros*/
#define BASEPORT 0x378
#define CLK_HI p_data |= 0x08; outb(p_data,BASEPORT); usleep(1000)
#define CLK_LO p_data &=~0x08; outb(p_data,BASEPORT); usleep(1000)
#define nRST_HI p_data |= 0x04; outb(p_data,BASEPORT); usleep(1000)
#define nRST_LO p_data &=~0x04; outb(p_data,BASEPORT); usleep(1000)
#define D_HI outb(0x02, BASEPORT+2); usleep(1000)
#define D_LO outb(0x0A, BASEPORT+2); usleep(1000)
#define READ_BACK -((inb(BASEPORT+2) & 0x08) >> 3) + 1
/* define the Commands needed */
#define Read_Temp 0xAA
#define Write_Config 0x0C
#define Read_Config 0xAC
#define Start_Convert 0xEE
#define done_mask 0x80
#define nvb_mask 0x10
char p_data = 0xFF;
float LSB = 0.5;
/* prototypes */
int read_bit();
int read_part(int protocol, int n_bits);
void write_bit(int w_bit);
void write_part(int protocol, int param, int n_bits);
float temperature();
/*
* This is the main function called by other C programs in order to find
* out the temperature on the sensor. It assumes the printer port has
* already been opened correctly
*/
float temperature(void)
{
float read_temp;
/*
* Set mode on DS1620 to: CPU = 1 1Shot = 1
*/
write_part(Write_Config, 3, 8);
/*
* Wait until finished writing to E^2
*/
do {
printf("\nDevice Busy");
} while ((read_part(Read_Config, 8) & nvb_mask) == nvb_mask);
/*
* Start temperature conversion
*/
write_part(Start_Convert, 0, 0);
/*
* Wait until conversion is done
*/
do {
printf("\nConversion in progress");
} while ((read_part(Read_Config, 8) & done_mask) != done_mask);
/*
* Read temperature
*/
read_temp = (float) (read_part(Read_Temp, 9)) * LSB;
if ((int) read_temp >> 7 > 0)
read_temp -= 256;
return (read_temp);
}
/*
* reads one bit of data from DQ
*/
int read_bit()
{
int i;
CLK_LO;
i = READ_BACK;
CLK_HI;
return (i);
}
int read_part(int protocol, int n_bits)
{
int index, data;
int r_data = 0;
nRST_HI;
for (index = 0; index < 8; index++) {
data = protocol >> index;
data &= 0x01;
write_bit(data);
}
for (index = 0; index < n_bits; index++) {
r_data |= read_bit() << index;
}
nRST_LO;
return (r_data);
}
void write_bit(int w_bit)
{
if (w_bit == 0) {
D_LO;
}
else {
D_HI;
}
CLK_LO;
CLK_HI;
D_HI;
}
void write_part(int protocol, int param, int n_bits)
{
int index, data;
nRST_HI;
for (index = 0; index < 8; index++) {
data = protocol >> index;
data &= 0x01;
write_bit(data);
}
for (index = 0; index < n_bits; index++) {
data = param >> index;
data &= 0x01;
write_bit(data);
}
nRST_LO;
}
htmlbuilder.c
/*
* Name: htmlbuilder.c:
*
* Purpose: provides a series of HTML templates which can be called to build
* the HTML documents needed. By providing status information to these
* functions the correct web page is built
*
* Written by: Nathan Roche
*
* Modified: 11/9/1999
*
*/
#include <stdio.h>
#include <unistd.h>
#define VANDREFRESH 1 /* refresh time for vandalism html */
#define STATREFRESH 1 /* refresh time for stat report html */
#define TEMPREFRESH 1 /* refresh time for stat report html */
#define MAXVIEW 8 /* max cokes "shown" on webpage */
#define NUMBER_COLUMNS 8
/* prototypes */
/* these templates are called by other C programs to build HTML docs */
int template1 (int value[NUMBER_COLUMNS], char *filename);
int template2 (int vandswitch, char *filename);
int template3 (char *strtemp, char *filename);
void temp1_drawcoke(int number_bottles,FILE *filepointer);
void temp1_drawcoke_nr(int number, FILE *filepointer);
void temp1_html(int htmlpartno, FILE *filepointer, char *filename);
void temp2_html(int htmlpartno, FILE *filepointer, char *filename);
void temp3_html(int htmlpartno, FILE *filepointer, char *filename,
char *strtemp);
/*
* Builds the html file used for the stock status frame on the coke.pc webpage
*
*/
int template1 (int value[NUMBER_COLUMNS], char *filename){
int i;
FILE *fp;
if (fp = fopen(filename, "w")){
/*
* Show coke bottles in the viewable range for
* all columns as images in html file
*/
temp1_html(1,fp,filename);
for (i = 0; i < NUMBER_COLUMNS; i++){
temp1_drawcoke(value[i],fp);
if (i != NUMBER_COLUMNS - 1)
}
/*
* Show actual numbers associated with
* cokes/column, as text in html file
*/
for (i = 0; i < NUMBER_COLUMNS; i++){
temp1_drawcoke_nr(value[i],fp);
if (i != NUMBER_COLUMNS - 1)
}
temp1_html(4,fp, filename);
fclose(fp);
return(1);
}else
return(0);
}
/*
* Builds the html file used for the vandalism frame on the coke.pc webpage
*
*/
int template2 (int vandswitch, char *filename){
FILE *vand;
if (vand = fopen(filename, "w")){
temp2_html(1,vand,filename);
if (vandswitch == 0)
else
fclose(vand);
return(1);
} else
return(0);
}
/*
* Builds the html file used for the internal temperature frame on the
* coke.pc webpage
*
*/
int template3 (char *strtemp, char *filename){
FILE *temperature;
if (temperature = fopen(filename, "w")){
temp3_html(1, temperature, filename, strtemp);
fclose(temperature);
return(1);
} else
return(0);
}
/*
* Writes the amount of coke bottles in a a viewable range as images to the html
* file.
*
* Called by: template1
*
*/
void temp1_drawcoke(int number_bottles,FILE *filepointer){
int i;
fputs("<CENTER>",filepointer);
for (i = MAXVIEW; i > 0; i--){
if (number_bottles - i >= 0)
fputs("<IMG SRC=\"dot.gif\">",filepointer);
else
fputs("<IMG SRC=\"nodot.gif\">",filepointer);
fputs("<BR>",filepointer);
}
fputs("</CENTER>",filepointer);
}
/*
* Writes the number of coke bottles as text to the html file
*
*
*/
void temp1_drawcoke_nr(int number, FILE *filepointer){
fprintf(filepointer,"<CENTER><FONT
SIZE=+10><B>%d</B></FONT></CENTER>",number);
}
/*
* Writes specific html sections to the file for the stock status frame
*
*
*/
void temp1_html(int htmlpartno, FILE *filepointer, char *filename){
if(htmlpartno == 1){
fprintf(filepointer,"
<HTML><HEAD><META HTTP-EQUIV=REFRESH
CONTENT=\"%d;URL=http://coke.pc.elec.uq.edu.au/%s\">
", STATREFRESH, filename);
fputs("
<TITLE>COKE.NET | STATUS REPORT</TITLE>
</HEAD><BODY BGCOLOR=DARKRED LINK=YELLOW ALINK=WHITE
VLINK=WHITE>
<CENTER><FONT COLOR=WHITE><B>STATUS REPORT:</B></FONT>
<TABLE BORDER=5 WIDTH=600>
<TR><TD BGCOLOR=RED>
<CENTER><FONT
COLOR=WHITE><B>COKE</B></FONT></CENTER>
</TD><TD BGCOLOR=RED>
<CENTER><FONT
<CENTER><FONT
<CENTER><FONT
</TD><TD BGCOLOR=ORANGE>
<CENTER><B>FANTA</B></CENTER>
</TD><TD BGCOLOR=YELLOW>
<CENTER><B>LIFT</B></CENTER>
</TD><TD BGCOLOR=GREEN>
<CENTER><FONT
COLOR=WHITE><B>SPRITE</B><FONT></CENTER>
</TD><TD BGCOLOR=WHITE>
<CENTER><FONT COLOR=RED><B>DIET
<BR> COKE</B><FONT></CENTER>
</TD></TR><TR BGCOLOR=WHITE><TD>
",filepointer);
} else if(htmlpartno == 2)
fputs("
</TD><TD>
",filepointer);
else if(htmlpartno == 3)
fputs("
</TD></TR><TR BGCOLOR=LIGHTBLUE><TD>
",filepointer);
else if(htmlpartno == 4)
fputs("</TD></TABLE>
</CENTER></BODY></HTML>",filepointer);
}
/*
* Writes specific html sections to the file for the vandalism frame
*
*
*/
void temp2_html(int htmlpartno, FILE *filepointer, char *filename){
",VANDREFRESH,filename);
fputs("
<BODY BGCOLOR=DARKRED LINK=YELLOW ALINK=WHITE
VLINK=WHITE>
<CENTER><FONT COLOR=WHITE><B>MACHINE
CONDITION:</B></FONT>
",filepointer);
} else if (htmlpartno == 2)
fputs("
<TABLE BORDER=5 BGCOLOR=DARKGRAY WIDTH=600 HEIGHT=50
CELLPADDING=5>
<TR><TD>
<CENTER>
<FONT SIZE=+3
COLOR=WHITE><B>OPERATIONAL</B></FONT>
</CENTER>
</TD></TR>
</TABLE>,</HTML>
",filepointer);
else if (htmlpartno == 3)
<TABLE BORDER=5 BGCOLOR=BLACK WIDTH=600 HEIGHT=30
CELLPADDING=5>
<TR><TD>
<CENTER>
<FONT SIZE=+3 COLOR=WHITE><BLINK><B>
POSSIBLE VANDALISM</B></BLINK></FONT>
</CENTER>
</TD><TD>
<P ALIGN=\"center\">
<FORM ACTION=\"/cgi-bin/vandreset.cgi\" method=\"POST\">
<INPUT TYPE=\"hidden\" NAME=\"url\"
value=\"http://coke.pc.elec.uq.edu.au/%s\">
<INPUT TYPE=\"submit\" value =\" RESET
\"></STRONG></SMALL>
</FORM>
</P>
</TD></TR></TABLE></HTML>
",filename);
}
/*
* Writes specific html sections to the file for the internal temperature
* frame
*
*
*/
void temp3_html(int htmlpartno, FILE *filepointer, char *filename,
char *strtemp){
",TEMPREFRESH,filename);
<BODY BGCOLOR=darkred>
<CENTER>
<FONT COLOR=WHITE><B>MACHINE CONDITION:</B></FONT><P>
<TABLE BORDER=5 BGCOLOR=RED cellpadding=3>
<TR>
<TD>
<FONT SIZE=+6 COLOR=WHITE> %s </FONT>
</TD>
</TR>
</TABLE>
</CENTER>
</BODY>
</HTML>
",strtemp);
}
}

BRIO

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BRIO

Uploaded by

Copyright:

Available Formats

c cc c

You might also like