Figure 1.2.1
Courtesy of Ryan Wigley and Derek Creech
Ryan Wigley and Derek Creech built such a device , and Mr. Voorhees and Mr. Korb modified the prototype such that it effectively communicates with the Eos network. The device can now successfully update user's quota, and it can it access a database of user IDs. A picture of PAWS is shown in figure 1.2.1.
A development environment was procured to simulate the communications activity of
PAWS and facilitate it's installation. The installation of the PAWS device onto
an Eos server is designed to be a trivial undertaking.
Access to the students login ID via student ID number will be on a secure privileged
server. Only the student ID number will be available for the student to
view. In this manner, a student has no useful access to the PAWS
database of user ID strings and student ID numbers except to update print
quota to a particular student ID.
A log of transactions is kept so that accounts may be balanced with
money received by the PAWS device. See the software manual in Appendix C
for details.
The majority of the code for the PAWS host server and it's slave programs
will be written in PERL 4. This will insure cross platform compatibility across
BSD Unix systems and close compatibility with System V Unix.
Documentation of the code and a software manual will facilitate maintenance of the server program (see Appendix C).
The bill reader itself is of standard industrial design, but a more modern
equivalent would be desirable. The same operating principals should be
transferable to another bill reader.
The use of student ID numbers was considered a distinguishing way to verify
a student's identity, and also a number that most students know. The
interface to the students is a 16 by 2 character display so that feedback
can be delivered to the student while using the device.
The MC68HC711E9 has 512 bytes of RAM and 512 bytes of EEPROM.
Because we cannot ensure that the power will not be interrupted, the design
requires that the program and data be stored in either EEPROM or EPROM.
This design
needs 3k of memory which is more than accommodated by the 12k internal EPROM the 711 chip provides.
Burning the BUFFALO monitor into the EPROM was considered because of
the ease of using a monitor, but was abandoned when we found that it would take
almost all of our volatile EPROM. A monitor emulator that runs on
a MS-DOS platform was used.
The MC68HC711 micro-controller is a full featured processor easily
capable of handling the tasks of controlling the user interface. The MC68HC711
has five built in ports labeled A thru E. These are used to access the LCD, keypad,
bill reader, serial interface and a LED indicator.
The interfacing to these components was already completed by Mr. Creech and
Mr. Wigley.
A block diagram of the micro-controller interface
is shown in figure 3.1.1. and a schematic of the wiring harness is presented
in Appendix B. Few alterations were made to the original hardware prototype, though since there
was more usable memory, the user interface was fleshed out somewhat.
The PAWS device communicates with it's host through an RS-232 serial connection
using 8 bit, 1 stop bit, no parity. Since the device transmits and receives a
maximum of 15 bytes at a time, a complex protocol seemed unwarranted.
Since the majority of the host server program
and assisting programs is written in PERL 4,
it will not be difficult to move the server program
from the DECstation development
environment to a Sun Sparc or DEC Alpha based server in the Leazar server
room.
Enter ID Number
As the user hits the keys to enter their ID number PAWS displays the numbers
on the screen. If the user makes a mistake they can correct the error with
either the backspace key (B), or with the clear key (C). Both are clearly
labeled on the PAWS device. Also they can quit the transaction at any time
with the abort key (A). When all nine numbers of the student ID number have
been entered PAWS automatically initiates the lookup process with the
PAWS host. It sends the ID number along with the lookup command through the
serial connection. The PAWS device then waits a standard amount of time for
the host to respond with the lookup results. The host is logged into Eos
in privileged mode, and searches an SQL database for a login ID that matches
the student ID number inputted. The login is then returned to the host
and used in the lpquota command
to find out the user quota data. The PAWS host parses through this data to
determine whether printing is off or on, and how much quota the person has. The
host then returns the results of this lookup to the device through the serial
connection with a tag to indicate a successful or unsuccessful transaction.
If the lookup failed the PAWS device displays:
ID# XXXXXXXXX
And returns to the scrolling messages after a short pause. If it passed the
lookup the PAWS device displays:
ID# XXXXXXXXX
After a short pause it displays the quota information returned by the host. If
printing is turned off the display is the following
Quota=-XX.XX off
If printing is on the display is the following:
Quota=+XX.XX on
If the host is having network problems or is down and the PAWS device does
not get a response within the allotted time the device displays messages that the
communication is down and tries to synchronizes the connection.
At the "Insert $5.00" prompt, the user has 45 seconds to insert a $5.00 bill
into the bill acceptor. This is to allow for those old wrinkled up bills that
take a few attempts to satisfy the bill acceptor. When the 45 seconds are
up and no bills have been entered the device will cut the bill machine off and
ask if you would like more time.
Need more time ?
If there is no response in 15 seconds the device quits the transaction and
goes back to scrolling the messages.
If the user does insert a bill in the 45 second window the device sends the ID
number of the user with the increase command. The host performs an increase
of the user's print quota by $5.00 on the Eos system
and if $5.00 is greater than or equal to what was needed,
printing is turned on for the user. The host also sends the newly
updated information to PAWS
The PAWS device then quickly displays:
Bill accepted
Then after a short pause it shows the user the updated quota information:
Quota=(+/-)XX.XX (on/off)
The PAWS device and host can indefinitely update a users quota like this.
If the user wants to quit they can hit the (D) key for done or simply walk off.
The device with wait for a bill 45 seconds then for 15 more seconds then return
to the wait state of scrolling.
If the device does not get a response from the host when it is trying to
increase quota it will display a warning screen for the user. This screen tells
the user to check if their quota has been increased. If PAWS failed to
increase their quota but took their money they are told to go to Wolf Copy for
assistance.
A simplified flow chart is shown in figure 4.3.1.
A PERL program was also written to parse a flat file of imaginary users and
student ID numbers such that a user name would be returned if queried on
a student ID number.
Recently, an SQL database table was procured from the Computer Science Department.
SybPERL was used to perform the same function as the file parser, but
using Sybase instead.
User names were successfully retrieved in this way, and the experimental
SQL table used is of the same form as the hes_db.dbo.userinfo table that
would be used in the final installation of PAWS. This code is incorporated
into the PAWS host program.
The PAWS host program incorporates many service routines to serve
PAWS the information it requests via serial connection. The program
maintains an infinite loop that waits for command directives from PAWS.
A separate program conditions the serial line to match that of PAWS as
8 bits, one stop bit and no parity. This program reinitializes the serial
line once every second to maintain the device configuration on a DEC 3100.
When the PAWS host receives a complete command string, it checks it for
conformity to known commands, and executes a lookup or an increase on lpquota
if the command is valid. If the command is invalid, the host returns a
string indicating a failure in communication. The same failure string is
transmitted if the user's ID number is invalid, or if there is no lpquota
information regarding that user.
Upon a successful lookup of the user name using a SybPERL query of it's
database, the host executes an lpquota command for that user, and parses
the information on the user's quota limit and usage. The command would look
like this from a shell on the Eos system:
Only the third line is examined, and the limit amount is subtracted
from the usage amount. This number is rounded into a string conforming
to dollars and cents conventions, and appended to a return string for PAWS.
This string is sent down the serial port for PAWS and the program waits
for more input.
An increase command from PAWS initiates a similar course of action,
except that the lpquota command is altered to affect an increase on the
user's quota, and if their usage is less than or equal to their limit,
printing is turned on by using the -f1 switch in the lpquota command.
The command would look like this from a shell on the Eos system:
Again, the third line is examined, and the information is returned to PAWS.
A program is provided to show how much money is in the box for accounting
purposes. One simply enters the date and time the money was last removed
from the box, and the program parses the log file after that time stamp
to collect data on the transactions, displaying the received total on the
screen.
This document and complete appendices will be stored in
file://localhost/afs/eos/info/eos_info/www/eos/hardware/technician/
which has access limited to only IT&ECS employees who will support the
hardware and software of the PAWS system.
Programming a MC68HC11 can be a long and arduous task when most of it's
function is I/O. Much of what our device was doing was sending instructions
to the LCD display, taking input from the keyboard, and maintaining serial
communication with the host. Debugging was made much more difficult because
of these facts, but we endeavored to make the assembly code modular to
assist in tracking down problems. We also tried to put the questionable
routines into EEPROM rather than EPROM to try to save time and memory space
for multiple test down-loads.
We are grateful to Ryan Wigley and Derek Creech for outlining the design
beforehand, allowing us to get right to work on implementation. We only
needed to request materials from our sponsor, and proceed along design
specifications that were already in place.
Many people consulted on this task suggested using C to program the service
routines, but PERL has been shown to be as powerful as C, and as evidenced
by this project, it is rather easy to port PERL programs over different
platforms. Serial communication in PERL is predictable and practical, and
development was quite speedy using this scripting language. The SybPERL
extensions make database queries a simple task, and the code embedded in
the service program is small and clear.
2 Project Analysis
Many issues are raised with the development of the PAWS device, including
security, maintainability, and usability.
2.1 Security
The PAWS device will be installed in 100 Leazar which currently maintains
24 hour security over the equipment in the lab. The PAWS bill acceptor
is in a standard wall mounted strong box with "key in crank" access to
received payment.
2.2 Maintainability
The micro-controller is a 68HC711 made by Motorola. This is a popular
micro-controller with a great deal of support from Motorola and by
developers all over the world. Code for PAWS will be stored in
EPROM and EEPROM on the device itself, and cannot be erased except with intense
ultra-violet radiation. However, should the code fail, or need adjustment,
source code will be available with documentation on a World
Wide Web site with access limited to authorized PAWS operators such
as WolfCopy, the Computing Center and IT&ECS.
2.3 Usability
24 hour print quota access makes adding print quota much more convenient. Since
the PAWS device is located in the largest public Eos lab, most students
will not need to walk very far in order to update their quota. Cumbersome
paperwork need not be filled out, and the traditional wait for up to 1 hour
for print quota to be updated will be eliminated.
3 Design Considerations
3.1 Processing Platform
The micro-controller used is from the Motorola MC68HC11 microprocessor
family, specifically, the MC68HC711E9 which has a built in 12k EPROM.
Figure 3.1.13.2 Host Server
The host server for PAWS must accomplish a variety of tasks. It must
be able to communicate with the PAWS device via serial cable, and it
must also be able to communicate with the Eos network in a privileged mode.
Two privileged actions are required of the PAWS server. It must be
able to access a database with both user ID strings and student ID numbers.
Secondly, it must be able to increase a users print quota.
Other actions, such as record keeping and user interface service will also
be necessary.
4 Design Decisions and Implementation
Many of the project parameters were already fixed by Ryan Wigley and Derek Creech when
they prototyped PAWS for their senior design project.
4.1 The 68HC711 Micro-controller
More memory was needed to hold the final version of the assembly code for the MC68HC11. An MC68HC711 would provide 12k of EPROM which would be more than
adequate for our project.
Finding working MC68HC711 processors was a non-trivial task. This combined with
the fact that those micro-controllers are back ordered six months caused dismay. We considered
changing the operating mode of the MC68HC11 to expanded mode. In expanded mode
the address, data, and control lines of the processor can be used to access a
large variety of components. This would be advantageous since we could add
arbitrary amounts of EPROM.
RAM could also be installed for development work, bypassing the
time consuming program and erase cycle of an EPROM. The cost was losing three
of the built in ports of the MC68HC11. This would throw out all the interfacing
work completed already. Fortunately, a working MC68HC711 was located. The
integration of the MC68HC711 into the PAWS unit was nearly seamless, though
as mentioned before, we were not able to use the BUFFALO monitor program
and were compelled to use the free-ware PC Bug to perform down-loading
and simulation.
4.2 Interface of PAWS to Eos
A DECstation 3100 was appropriated as a development platform for PAWS server
construction.
Programs were created in PERL 4 to
simulate the action of the lpquota command in privileged mode, and access
to a flat file of user IDs and student ID numbers.
An SQL database was also procured to simulate the hes_db.dbo.userinfo
SQL database that
already exists on campus. To use the campus database, the account
and password fields will need to be changed in the PAWS service program to
access the privileged table. A data flow diagram of the PAWS system appears
in Figure 4.2.1.
Figure
4.2.14.3 Function of PAWS
The PAWS host server constantly monitors the serial port that the PAWS
device is connected to. The PAWS device, in it's wait state, displays
scrolling messages to the passers by. The messages are to attract attention and
interest in using the PAWS device. These messages of propaganda continuously
bombard the public in a variety of scrolling styles. When a user walks up and
hits any key PAWS is set into action. It displays the input screen:
>_
Failed lookup!!!
account verified
Insert $5 bills
Insert $5 bills
D/Yes / A/No
Quota up $5.00
Insert $5 bills
Figure 4.3.14.4 Activity of the PAWS Host Server
The details of how the host communicates with PAWS are withheld for security
reasons, but an overview is presented here. Appendix C is available with the
source code for privileged readers. The host program was developed and tested
on a DECstation 3100.
4.4.1 Simulation of lpquota command and SQL database
A program was written in PERL to simulate the actions of the lpquota
command when used by a privileged user. Normally, a user can only
check their own printer quota status, and is barred from increasing his/her
printer quota on their own or anyone else's account. Privileged users
may view all other user's quota status and manipulate other user's printer
quota in a variety of ways, but an increase of $5.00 is all we are interested
in. All lpquota commands return the current printer quota status for the
user.
4.4.2 The PAWS Host Program
eos%lpquota -Plez100 userid
Username : userid
Service : eos
Usage: $60.97 Limit: $65.00
Last bill: $0.00 Ytd billed: $0.00
Printing is allowed
eos%lpquota -f1 -Plez100 -i 500 userid
Username : userid
Service : eos
Usage: $60.97 Limit: $70.00
Last bill: $0.00 Ytd billed: $0.00
Printing is allowed
4.5 Maintenance and Service to the PAWS System
The PAWS host keeps a continuous log of each transaction, including a time
stamp, the message received from PAWS, the user name of the customer,
and the acknowledgment string sent back to PAWS. This log may be viewed
by a text editor available on the Eos system.
5 Observations and Conclusions
Getting a micro-controller to talk to a computer is a non-trivial endeavor.
Unix has many approaches to serial line conditioning, and none of these
are uniform across platforms. We thought it interesting that a DEC 3100
will "forget" it's line conditioning commands unless you remind it on
occasion. It was also interesting that different Linux machines respond
differently to serial communication, though they all claim to be "IBM compatible".