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.
Our design is broken up into several components. After solving each component individually, they were pieced together to form a complete system.
Television
As the primary display for the client machine, the television is an integral part of the voting machine. The display is text only the code driving it was optimized for such a purpose.
Card reader
The card reader used is a standard track two reader. For most cards, track two stores data that is easily accessible via other means (i.e. credit card numbers, student ID number, driver’s license number). When a user swipes their card, the machine will authenticate the number as valid (in our case, a valid Cornell ID) and allow the person to continue. If the card is not of the proper format, an error is returned. For our purposes, the student ID number is sufficient for authentication.
Communication between multiple chips via TWI
Since we planned on allowing multiple devices to simultaneously connect to one server, we needed to use some sort of common bus. Fortunately, the Mega32 has such a feature in the form of the Two Wire Interface. As the name implies, the TWI has two wires; one for a clock pulse and another for data. Since there can be multiple devices on the bus, the TWI also uses device addressing and a master/slave system to determine which devices are allowed to “talk” at any given time. By implementing some more robust communication protocols, data can be sent from the client to the server for verification and an acknowledgement can be sent from the server to the client.
Printer
Since digital data can be compromised and altered, we decided to implement a method to create a hard copy of a user’s selection. After a person has finished entering his or her choices and the data is verified, the text is sent out to the printer attached to the machine. After some experimentation, we discovered this was fairly simple to do, since it only required feeding the data through the serial port, followed by a form feed to start the printer.
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.
ISO 7811
Stripes on the magnetic cards normally use the same format as bank or financial cards, (ISO 7811). We only use track two which contains up to 40 bits of numeric data. A number is represented as a 5 bit number, the least significant bit transmitted first then followed by an odd parity bit. A sequence of zeros are transmitted from the reader, to help with alignment then the first character is sentinel character signifying the start of the sequence. Next the data and finally a end sequence character with one last numerical data. This last character of data serves as a longitudinal redundancy check. It contains the bit sum of each previously transmitted character. Using this information means at least 4 errors must exists before an invalid card can be read as valid.
ASCII
American Standard Code for Information Interchange what used to represent alphanumeric characters and symbol on both the TV screen and the printer. Ascii is character set that uses 7 bits to represent most symbols, and is commonly in use today. Other possible implementations included the ascii extended and ansi charcterset.
EAC
The America vote act legislation passed in 2002 provided a set of voluntary voting guidelines to be implemented by the Federal Election Commissions (FEC) and the election assistance commission (EAC). These guidelines address every type of voting system including electronic voting, known as Direct Recording Electronic. Listing the requirements of the machines with users and interfaces, allong with testign guidelines. The full 200 page report is available at EAC.
As mentioned earlier, our design is not the first of its kind. Several patents are currently on file with the US Patent and Trade Office, including several “Electronic voting systems” and “Computerized voting systems.” Most of these patents are only a few years old and outline basic polling systems similar to ours. These include patent numbers:
In addition, patent number 4373134 includes specifications for a voting system using magnetic card authentication (similar to our design). This patent, however, was filed over 20 years ago and has most likely expired.
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.
During tests, our design works as expected. The primary metric for our project would be accuracy. This has been tested to the best of our ability, but since we don't have the means to performa a large scale deployment, we are unable to fully test the expandability. We have been able to accurately tally up votes and display them on the PC interface. In addition, extensive testing has been done on the communication via the two-wire-interface. We have ensured that a robust protocol controls the data flow between the various clients and the server. When two clients try to communicate with the server at once, proper measures are taken to keep one person talking at at time.
In our experience, our design has not caused any sort of interference with neighboring devices. It does not generate or emit any sort of harmful interference that could damage another device. By keeping the interface simple, most users will be able to quickly adapt and enter information.
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 text-only 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.
- Appendix A:Printer Code
- Appendix B:Server Code
- Appendix C:Client Code
- Appendix D:cardReader Code
- Appendix E:Video Code
- Appendix F:TWICode
- Parts List and Cost
Click above links to download
0 comments:
Post a Comment