Introduction

Our project is an electronic voting system. The system allows for quick and accurate voting electronically. The system uses a client/server architecture, which allows voters to cast ballots on the client terminal. Each client interfaces with the server, which keeps track of the entire system.

High Level Design

Our design is broken up into several components. After solving each component individually, they were pieced together to form a complete system

Hardware/Software Tradeoffs
Client/Server architecture. The inherent tradeoff in this architecture is that the server requires more storage and processing power to be able to fulfill all client requests. This also creates a vulnerability in the system since it is a key component. A server compromise would be disastrous. However, coding a verification transaction protocol becomes much simpler in a client/server architecture. An alternative would be a peer to peer system. In this method, a machine must communicate with every other machine on each transaction. Furthermore if any of the client machines where to go down, they will not be able to respond to requests. A client/server architecture is advantageous in this scenario as it simplifies programming and makes the system easier to control. TV output

Since the output was simple text, an LCD screen may have been sufficient to provide the same level of information as a TV screen. Since the TV screens are not considered part of the budget, they were chosen over the somewhat expensive LCD screens. As a tradeoff, a more complex (and more expensive) chip was required. In addition, the Mega32 provided us with functionality in serial interfaces that would be used for I/O simplifying our code. Printer Interface To print, we elected to use a serial interface. This is relatively low tech and easy to implement since almost every printer has the ability to take ASCII characters as input. The ability to use newer and more feature rich printers would require the use of postscript. This would allow for graphics and nicer looking text since printing is based on a language which describes a series of geometric shapes and intensity. As a result of simple printing, the paper ballots are easily reproducible, and more complex hardware would have been needed to provide more protection. Secure MCU Atmel has a series of secure microcontrollers. These micocontrollers are much more expensive than the regular AVR class. These microcontrollers have dedicated hardware to prefrom cryptographic operations in parallel to normal program execution. In addition is provides two operations of user and super user modes, to protect accesses to memory. It can self monitor external voltage and frequency to detect tampering, this chip is much more reallible and secure for such a task. Since we used simple logic we had to attempt to include this type reliability in hardware.

Program/Hardware Design
Software Design
The bulk of our design was to get several different components to work together to form one coherent system. Each component was designed, coded and tested individually before being integrated. Furthermore, since there are two distinct tasks Server or client, 2 different codebases are needed. Server The server uses the Verify, Commit and Crashrecovery functions to maintain correct state on the machine. He server is continously running listening on its TWI bus. Once the server has been addressed, it stores the data in a temporary buffer, once the entire message has been recieved it uses verify to determine that the ID number has not been

used allready, and sets a flag. The server only uses commit to store this data once the, the protocal has sent a response back to client and has confirmed with and acknowledgement on the TWI bus. BackupmaxIDA++; IDarray[maxID]=newID; BackupIDarray[maxID]=newID; maxID++; voteArray[0][temp[5]]++; .... BackupvoteArray[0][temp[5]]++; ... BackupmaxIDB++; BackupmaxIDC++; This code segment is for our commit function, and works hand in hand with crash recovery. All the backup datatypes are stored in EEPROM memory, this memory will survive a crash. The ID are stored as long variable and take up 4 bytes this means that an access to them could be interrupted and the ID not written correctly. The multiple Backup varialbes are used to determine when a crash occured. Since each of these varaibles are char, I am guaranted that they either either correct or incorrect. If A, B and C are equal that means the system is in a coherent state. By using the relations between these 3 varaibles we can determine where the error occured and correct the voting list. However without error correcting codes there is no way to recover the actual voter data or votes register. That is why each machine has a paper trail. The TWI interface has a build in state machine. Each interrupt from the TWI inteface provides a status flag, this status flag represent the sate of the TWI bus and the current machine. The application only has to create responses to these states. The only state that is needed are flag to notify when buffers are empty to stop transmission of data. Client The client machines output to the TV. The TV code has been reworked from having a raster based display to that of ascii decoder. The old raster display would output one char, one bit at a time in 5 cycles. Since the code was not fast enough all the bytes had to be preloaded and then sent out. The base simplification to save time was that the entire port was dedicated for video display. This means that no other pins on the port can be used for output. This reduced the number of operations to ouput from 5 to 2. These 3 additional cycles where used to load and process the next output. The output is limited to 5x7 chacters with a blank line between characters(vertically), thus the

display is 5x8 characters. The characters are stored as regular ASCII text. Flash memory contains the bitmaps for charcters 0-127, with character 10 (newline) being special. While outputting one character, the code loads in the next chacter by looking up that character in flash. Another feture is that the code automatically checks for a newline and proceds to the next line. Previously a screen occupied 1600 bytes in memory, the same output of pure text only costs 200~300 bytes. This was necesarry since the large amount of text display. The only thing the code needs is a char pointer. By setting Page Start to any character array. This also mean that redrawing the screen is very fast.

Hardware
Our design is comprised of 6 main parts: identification, input, output, verification, storage and communication. Each of these parts were designed and tested independently before being combined into the final system. Identification For identification, magnetic card readers were used. Magnetic stripe cards are commonly available and are in widespread use. Most states provide identification cards that contain some information on a magnetic strip. At Cornell, every student is issued a Cornell ID which has a stripe. The card communicates raw bit data serially to the microcontroller for processing. The microcontroller then decides if the card is a valid Cornell ID. The Card readers used were TTL chips, that provided a clock, data, and card present. These where used in conjuction with the Serial Peripheral Interface ehich matches up nicely. The SPI has serial clcok, serial data and slave select. Reciving the bitstream from the card was not difficult except for buffer overrun errors and variable speed clock (dependent on the swipe speed). Input Input to the voting machine is very simple. The user chooses from a list of options from a menu, and moves between different ballot questions via four pushbuttons. The buttons represent Go Back a Page, Select Up, Select Down and OK. Output The user interface is displayed via a television monitor. Since TV screens are widely available, they can easily be replaced. The output of the microcontroller is in NTSC format black and white. The TV output is actually a matrix of 14 by 25 ASCII

characters (instead of a full raster). This implementation is extremely memory efficient, since each character requires one byte to store. For example, a blank screen requires only 14 bytes to store, since each line only contains a new-line character. Storage The votes are stored in multiple places. All the selections made on the ballet are initially stored in volatile SRAM memory until the vote is committed. Once the vote is committed to the server, the votes are moved from SRAM to the longer lasting EEPROM and are also printed out to provide a hard copy. Additionally, the server keeps a running tally after the verification step. Communication The communication between the server and clients are using and addressable serial interface called TWI. This interface allows for each component to have a specific address when in the network. Each voting machine knowns the address of the Server machine and sends a request to that address and waits for a response. This interface requires an external pull up resister network and that all chips connect to. If any of the devices are not on, the serial communication will not function, even if its not the intented reciever. The Server also uses the USART interface to connect to a computer and provide terminal commands.

Conclusions
Our final design far exceeded our initial expectations. Initially, we only planned on creating a single machine with card reader. However, after further investigation, we were able to figure out how the two wire interface worked, which allowed us to network several chips together. This then required implementing a network protocol of sorts to govern the communication between machines. This proved to be somewhat troublesome, as the protocol required the operation of a complex state machine. In addition to the TWI, we were also able to implement the PC interface for the server and printer for the client. Both were less challenging than expected, though each required thourough understanding of each system's intracacies. For example, the serial connection for the printer was not the same as the standard connection provided in lab. Instead, the two data lines are reversed. We also needed to locate a serial port of the opposite gender. The PC interface was not as complete as we had hoped, since we also would have liked to implement a feature to allow the operator to change information on the entire system. Such functions would include resetting all the

machines, polling for data, and changing the questions on the entire system. This would have allowed the entire system to be even more expandable and more robust. We had also aquired a text-to-speech module, but didn't have time to research and implement it. The majority of the code for this project was done from scratch. However, some pieces were taken from past projects and modified in order to save time. Code for the serial port, pushbuttons, and timer interrupts were tweaked to work in our context. Menu code from the security system was also used as a basis for our PC interface. The video code we used could probably be reused by future generations who need textonly capabilities.

Ethics
"to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment" --Our design was made with usability in mind. It is relatively safe to use and poses little danger to the welfare of others "to avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist" --Our design was made in the best interest of a fair election or poll. "to be honest and realistic in stating claims or estimates based on available data" --We don't promise the moon, nor do we try to deliver it. Our design does what we describe. "to reject bribery in all its forms" --We took no bribes to bias the machine for any particular cause or organization. Data integrity from our perspective is safe. "to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations" --We were able to learn a few new things in doing this design, knowledge that may be useful in the future. "to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others" --The professor and teaching assistants were of great help when we got stuck on

problems. "to treat fairly all persons regardless of such factors as race, religion, gender, disability, age, or national origin" --A card reader does not (and can not) discriminate. "to avoid injuring others, their property, reputation, or employment by false or malicious action" --Our design does not include devices that could cause harm with malicious intent. It's a simple polling machine that tallys up ballot responses. "to assist colleagues and co-workers in their professional development and to support them in following this code of ethics" --We've helped out other groups on several occasions when they had issues with hardware or software.