Electronic Voting System for a Legislative Body

Project Plan

Senior Design: May 02-05

Michael T. Riley

Robert Ernst Meyer III

Dan Phan-Quoc Kieu

Client: Government of the Student Body (GSB)

Faculty Advisors:Dr. J.W. Lamont

Dr. R.E. Patterson III

September 24, 2001

Table of Contents

List of Figures

List of Tables

ABSTRACT:

ACKNOWLEDGEMENTS:

DEFINITION OF TERMS:

INTRODUCTION:

General Background:

Technical Problem:

Operating Environment:

Intended Users:

Assumptions and Limitations:

DESIGN REQUIREMENTS:

Design Objectives:

Functional Requirements:

Design Constraints:

Measurable Milestones:

END PRODUCT DESCRIPTION:

APPROACH and DESIGN:

Technical Approaches:

Technical Design:

Testing Description:

Risk & Risk Management:

FINANCIAL BUDGET:

PERSONNEL EFFORT BUDGET:

PROJECT SCHEDULE:

Gantt chart:

CLOSURE MATERIAL:

Project Team Information:

Summary:

References:

List of Figures

Figure 1: GSB Session Layout, Clerk at the top in the box...... 2

Figure 2: LCD-like Wall Display...... 5

Figure 3: Gantt chart...... 10

List of Tables

Table 1: Assumptions and Limitations...... 3

Table 2: Functional Requirements...... 4

Table 3: Preliminary Budget...... 9

Table 4: Preliminary Personnel Effort Budget...... 9

ABSTRACT:

Voting in a legislative body can be a time consuming process, in that individual votes must be counted either by roll call or other means that is not time efficient. Thus having an electronic voting system where the legislative body members can register their votes simultaneously, this would greatly speed up the legislative process and allow the legislative body to accomplish more. This is particularly useful when the legislative body has to vote several times during a session.

The solution to this problem is to provide each legislative member with an electronic voting device that is connected to a computer (via a controller) that will automatically tally the votes and display the results and various statistics. The other major objective is to produce a voting system that is not only time efficient for the legislative body, but also cost effective. This allows the legislative body to be more effective in their sessions.

ACKNOWLEDGEMENTS:

We would like to acknowledge the active role of the Iowa State University: Government of the Student Body (GSB) for funding this project. Special thanks to GSB Senator and member of the Rules Committee: Kathryn Kallaher for her support and advice.

DEFINITION OF TERMS:

GSB:Government of the Student Body

LCD:Liquid Crystal Display

INTRODUCTION:

General Background:

The Government of the Student Body (hereby referred to as GSB) spends much of their time during legislative sessions voting on various issues. This process can tend to be tedious and time consuming as votes are taken one by one. Thus there is a need to save time by having an electronic voting that enables the senators to vote simultaneously. This requires each senator to have a voting module that allows them to cast either a ‘YES’, ‘NO’, ‘NOT VOTING’ or ‘ABSTAIN’ vote. This module would then interface to a controller, which would talk to a computer and consequently display the voting results in a popular spreadsheet such as Microsoft Excel. There must be one module for each senator with a number of modules in reserve for future GSB expansion. There must also be modules in place for replacement of badly damaged modules and parts available for minor repairs.

Technical Problem:

The major technical problem will be to design a cost effective voting system that is easy to use and maintain. GSB meets in a room that must be setup and torn down after each legislative session, thus having a rugged system that will take the abuse of constant wear and tear is required. This system must also be easy to use, as the senators will have various technical backgrounds. Another difficulty will be designing a system that uses a minimal amount of wires and connections. For example, if each unit requires 4 wires and there needs to be 50 units, that is over 200 wires to maintain and over 100 wires for the controller to read and send to the computer for processing of the votes. This system must also be expandable to a degree that will enable GSB to add more senators as Iowa State University (hereby referred to as ISU) grows and expands. At this time, the project is to design a system. There are several options available right now, that would require different design methods. For example, each module could be a micro-controller, thus requiring programming at the assembly level, and the controller could be similar. At the very least the computer side software will probably be programmed in C, with patches to Visual Basic for exportation to Microsoft Excel. Visual Basic patches will we used because of the lack of Visual Basic experience of the team members, ease of learning, and ease of implication.

Operating Environment:

The electronic voting system will be used primarily the Campanile room of the ISU Memorial Union. This layout is in the shape of a horseshoe with the secretary and computer at the head (see Figure 1). The voting modules and controller must be designed ruggedly to withstand weekly setup or tear down.

Figure 1: GSB Session Layout, Clerk at the top in the box.

Intended Users:

GSB Senators will be incorporating this system into their weekly session. There is also the possibility that senators from Inter-Residence Hall Association will adopt the system for their weekly meetings as well.

Assumptions and Limitations:

To better understand the possibilities for the voting system design, a list of assumptions and a close estimate to the limitations were prepared. The component of the project that is the most unfamiliar is the GSB itself. Therefore, most of the assumptions focused on the GSB and the respective knowledge of its members.

There are few limitations, but each limitation deserves full attention. The primary limitation is budget, as GSB has promised funds of up to 1000 dollars. The rest of the limitations involve the voting system itself, specifically the expandability, complexity, and security issues. Once the central controller (see Design Objectives, Pg. 4) has been designed, the possibility of altering that design to incorporate more users is near zero. Therefore, the main controller must be designed with this limitation in mind. Also, the GSB has limited time for each session; so the setup of tear down of the system must be low in complexity in order to fully improve on the time efficiency of the GSB, which is one of the fundamental requirements of this project. The final limitation deals with security, and the fact that will be no out-of-room connection (i.e. Internet) to compromise the security of the GSB and their voting sessions.

Table 1: Assumptions and Limitations

Assumptions / Limitations

GSB Senators are competent and require little or no training in the use of the system.
The GSB Secretary will be competent to use the software created and understand the basic operation of the electronic voting system.
The GSB Secretary will be familiar with Microsoft Excel.
GSB will officially approve funding.

Cost, limited to $1,000.
Limited expandability after controller is designed.
Complexity in setup and tear down, in that too complicated of a system will be rejected by GSB as an adequate solution.
The controlling computer will not be hooked up to the Internet for the security of the voting system.

DESIGN REQUIREMENTS:

Design Objectives:

The primary objective of this project is to provide a high performance, low maintenance voting system at a reasonable price. This can be achieved only after carefully reviewing a long list of functional requirements and a series of design constraints. These topics to be considered are detailed in the following pages.

Functional Requirements:

A list of essential functions has been compiled to facilitate the decision-making process. The list of functional requirements is shown in Table 2.

Table 2: Functional Requirements

Requirement

Description

Voting Options / There are four voting options that must be available to each senator and must all be selectable on the individual modules:

Yes
No
Abstain
Not Present

ID Referencing / There are two possible design options:

Each senator is assigned a module with a unique number programmed into that module. Votes are recorded based on that number.
Each module will possess the ability to let any senator log on with an assigned unique ID. Votes are recorded based on the ID number

Display of Results / There are several options for displaying results of an individual vote:

Visual Display – Purchasing a scrolling, single-line LED display
to provide the results of each vote to everyone present.
Projector – The purchase (or borrowing) of a computer projector (i.e. ELMO) to project the laptop’s screen onto a larger area viewable by everyone in attendance.
LCD on Module – Incorporating a liquid crystal display on the individual modules assigned to each senator. LCD would consist of two lines, twenty characters per line.
Imitation LCD Display – Creating a large-scale light board with LCD-like display capabilities (see Figure 5).
No Display – GSB may decide that a display is not financially sound.

Port to Microsoft Excel / Regardless of the manner in which the votes are received from the individual modules, the end result must be the same. A record must be kept of each senator and the manner in which they voted for each issue. The totals for each of the voting options must also be recorded. These records must all be recorded in a Microsoft Excel spreadsheet for ease of maintaining, readability, and for efficient tallying of votes.
Voting Issue Displayed / There are three options for the display of the issue currently being voted on:

No Display – The issue would be presented orally without the use of electronic display. The oral presentation of an issue is standard and will not be omitted even with the inclusion of an electronic display.
Visual Display – If the scrolling LED display were incorporated for presenting the voting outcome, it would also be programmed to display the issue being considered.
LCD on Module – If the individual module assigned to each senator contains a liquid crystal display, the display would be used to display the question to each senator.

Roll Call / There are two options for handling Roll Call:

Oral – Attendance will be taken orally, with the Clerk reading a senator’s name and recorded his or her presence or absence.
On Module – If the individual module assigned to each senator allows the senator to log in, this login procedure will be used to produce an electronic attendance record.

Figure 2: LCD-like Wall Display

Design Constraints:

During the design process, there will be many things that either hinder progress or render some options unattainable. One of the primary design constraints will be funding. GSB will provide a total of 1000 dollars in funding, and any additional costs would require personal funds from the group. Therefore, the final solution must come near the aforementioned budget limit of. Another major concern is the complexity of the design. The solution must take into account that the GSB must make full use of the time that they have, and so setup time, take down time, and training time must be minimal. Complexity is also an issue in regard to the actual building of the system. Since the group has been reduced to three members, total implementation time will rise drastically for each of the remaining members. The issue of maintenance is also a key constraint. If the final solution incorporates modules that require battery power, for example, the cost and time spent testing and replacing batteries must be evaluated with the rest of the design issues.

Measurable Milestones:

Each Milestone will be evaluated using the following scale, based on the particular milestone’s level of success:

0.Not attempted

1.Not successful at all

2.Somewhat successful

3.Successful

4.Very Successful

Extremely Successful

Design Finalization/Research and Development: This milestone involves actually working to determine the cost and effectiveness for each of the possible solutions. This would also include putting together a presentation for GSB on the possible solutions to allow them to decide which is best for them. Research and Development includes research for suitable parts used in each solution.

Funding and Design Approval: A presentation will be made to GSB to appeal for funding and to provide design/cost analysis. This presentation would in all likelihood be given using Microsoft PowerPoint and would include both detailed diagrams and descriptions along with cost analysis for each proposed solution.

Design: This stage involves finalizing any design issues given the approved solution, including cost, complexity, and upkeep.

Implementation/Software Development: This phase includes building the design and programming the computer interface.

Field Testing: Actual votes will be performed during a GSB session, with any errors/bugs that may appear being resolved at this time.

Final Approval: This stage has one goal: having the electronic voting system be approved by the GSB: Rules Committee so that it can be implemented in GSB policy.

Delivery: The final stage concludes the project by delivering the completed voting system to the GSB with full functionality.

END PRODUCT DESCRIPTION:

The Legislative Electronic Voting System will be used by GSB in their senate sessions. This system will include fifty modules being assigned individually to each senator that allow them to cast a ‘YES’, ‘NO’, ‘NOT VOTING’ or ‘ABSTAIN’ vote that a controller will recognize and be interfaced with a computer that will tally the voting results and report them in Microsoft Excel. Each module will incorporate the ability to identify each senator either by number or login.

APPROACH and DESIGN:

Technical Approaches:

The approach for this electronic voting system will include hardware and software. Software will be used to interface between the computer and controller to the voting system. There are many different hardware-related technical approaches, specifically the electrical wiring of the individual modules and the components that will be used to construct those modules. Various approaches include simple modules with switches to modules that have LCD’s and keypads for a more interactive voting experience. A major consideration is also being given to how to wire up the modules, both to cut down on complexity and to simplify the setup and tear down time. The final expected output is a system that is virtually foolproof and as simplistic as possible. Thus different design approaches are being considered on how to exactly wire the modules.

Technical Design:

The technical design of the system is divided into three parts: The modules, the controller, and the laptop. The laptop interface is static and all system configurations will input their data to the laptop, which will port the information into Microsoft Excel via software. There are various designs that are being considered for the modules and controller. The common goal of all module possibilities is to make them easily useable and rugged. The actual wiring of the modules is still under investigation, with proposed solutions ranging from wiring four switches to having each module contain a small microprocessor, keypad, and LCD. The controller will be designed based on the final module design selected. When reporting the design to GSB, material to be included all consists of the following: Pros/Cons, Cost, effectiveness, maintenance requirements, usefulness, ruggedness, ease of setup and ease of use. No criteria will be specified for rejecting or accepting a design, because the decision rests solely in the hands of the GSB.

Testing Description:

Testing will be done in the lab with regard to controller to computer interfacing. After this, several modules will be incorporated for a scaled down version of the complete system. After testing, more modules will be built and full scale testing on the floor of the Senate of the GSB will be done during or shortly after one of their weekly sessions.

Risk & Risk Management:

There are many risks associated with a project of this magnitude, including loss of funding, delayed part arrival, over-complexity and delay of software functionality. These issues are addressed in the following pages.

Risk #1: GSB funding failure

Probability: 20%

Impact: catastrophic

Contingency Plan: Work with the GSB representative to ensure GSB’s approval.

Risk #2: Cost exceeds funding

Probability: 25%

Impact: catastrophic

Contingency Plan: Develop design incorporating funding limitations.

Risk #3: Delayed product parts (such as modules)

Probability: 45%

Impact: Severe

Contingency Plan: Design the project goal around the shipment and delivery of parts so that the design and implementation is as independent from part delivery as possible.