Volume I, Section 4\
Table of Contents

4 Software Standards [4-1](#software-standards)

4.1 Scope [4-1](#scope)

4.1.1 Software Sources [4-2](#software-sources)

4.1.2 Location and Control of Software and Hardware on Which it Operates
[4-2](#location-and-control-of-software-and-hardware-on-which-it-operates)

4.1.3 Exclusions [4-3](#exclusions)

4.2 Software Design and Coding Standards
[4-3](#software-design-and-coding-standards)

4.2.1 Selection of Programming Languages
[4-3](#selection-of-programming-languages)

4.2.2 Software Integrity [4-4](#software-integrity)

4.2.3 Software Modularity and Programming
[4-5](#__RefHeading___Toc7170411)

4.2.4 Control Constructs [4-6](#__RefHeading___Toc7170412)

4.2.5 Naming Conventions [4-6](#__RefHeading___Toc7170413)

4.2.6 Coding Conventions [4-6](#coding-conventions)

4.2.7 Comment Conventions [4-7](#__RefHeading___Toc7170415)

4.3 Data and Document Retention [4-8](#__RefHeading___Toc7170416)

4.4 Audit Record Data [4-8](#audit-record-data)

4.4.1 Pre-election Audit Records [4-8](#pre-election-audit-records)

4.4.2 System Readiness Audit Records
[4-9](#system-readiness-audit-records)

4.4.3 In-Process Audit Records [4-9](#in-process-audit-records)

4.4.4 Vote Tally Data [4-10](#vote-tally-data)

4.5 Vote Secrecy (DRE Systems) [4-11](#vote-secrecy-dre-systems)

# Software Standards

## Scope

This section describes essential design and performance characteristics
of the software used in voting systems, addressing both system-level
software, such as operating systems, and voting system application
software, including firmware. The requirements of this section are
intended to ensure that voting system software is reliable, robust,
testable, and maintainable. The standards in this section also support
system accuracy, logical correctness, privacy, security and integrity.

The general requirements of this section apply to software used to
support the entire range of voting system activities described in
Section 2. More specific requirements are defined for ballot counting,
vote processing, creating an audit trail, and generating output reports
and files. Although this section emphasizes software, the standards
described also influence hardware design considerations.

This section recognizes that there is no best way to design software.
Many programming languages are available for which modern programming
practices are applicable, such as the use of rigorous program and data
structures, data typing, and naming conventions. Other programming
languages exist for which such practices are not easily applied.

The Standards are intended to guide the design of software written in
any of the programming languages commonly used for mainframe,
mini-computer, and microprocessor systems. They are not intended to
preclude the use of other languages or environments, such as those that
exhibit "declarative" structure, "object-oriented" languages,
"functional" programming languages, or any other combination of language
and implementation that provides appropriate levels of performance,
testability, reliability, and security. The vendor makes specific
software selections. However, the use of widely recognized and proven
software design methods will facilitate the analysis and testing of
voting system software in the qualification process.

### Software Sources

The requirements of this section apply generally to all software used in
voting systems, including:

-   Software provided by the voting system vendor and its component
    suppliers;

-   Software furnished by an external provider (for example, providers
    of COTS operating systems and web browsers) where the software may
    be used in any way during voting system operation; and

-   Software developed by the voting jurisdiction.

Compliance with the requirements of the software standards is assessed
by several formal tests, including code examination. Unmodified software
is not subject to code examination; however, source code generated by a
package and embedded in software modules for compilation or
interpretation shall be provided in human readable form to the VSTL. The
VSTL may inspect source code units to determine testing requirements or
to verify that the code is unmodified and that the default configuration
options have not been changed.

Configuration of software, both operating systems and applications, is
critical to proper system functioning. Correct test design and
sufficient test execution must account for the intended and proper
configuration of all system components. Therefore, the vendors shall
submit to the VSTL, in the TDP, a record of all user selections made
during software installation. The vendor shall also submit a record of
all configuration changes made to the software following its
installation. The VSTL shall confirm the propriety and correctness of
these user selections and configuration changes.

### Location and Control of Software and Hardware on Which it Operates

The requirements of this section apply to all software used in any
manner to support any voting-related activities, regardless of the
ownership of the software or the ownership and location of the hardware
on which the software is installed or operates. These requirements apply
to:

-   Software that operates on voting devices and vote counting devices
    installed at polling places under the control of the voting
    jurisdiction;

-   Software that operates on ballot printers, vote counting devices,
    and other hardware typically installed at central or precinct
    locations (including contractor facilities); and

-   Election management software.

However, some requirements apply only in specific situations indicated
in this section. In addition to the requirements of this section, all
software used in any manner to support any voting-related activities
shall meet the requirements for security described in Section 6 of the
Standards.

### Exclusions

Some voting systems use equipment, such as personal computers, that may
be used for other purposes and have resident on the equipment general
purpose software such as operating systems, programming language
compilers, database management systems, and Web browsers. Such software
is governed by the Standards unless:

-   The software provides no support of voting system capabilities;

-   The software is removable, disconnectable, or switchable such that
    it cannot function while voting system functions are enabled; and

-   Procedures are provided that confirm that the software has been
    removed, disconnected, or switched.

## Software Design and Coding Standards

The software used by voting systems is selected by the vendor and not
prescribed by the Standards. This section provides standards for voting
system software with regard to:

-   Selection of programming languages;

-   Software integrity;

-   Software modularity and programming;

-   Control constructs;

-   

-   Coding conventions; and

-   Comment conventions.

### Selection of Programming Languages 

Software associated with the logical and numerical operations of vote
data shall use a high-level programming language with support for
structured exception handling, such as Java, C++, C#, Visual Basic .NET,
or Ada. The requirement for the use of high-level language for logical
operations does not preclude the use of assembly language for
hardware-related segments, such as device controllers and handler
programs. Also, operating system software may be designed in assembly
language.

### Software Integrity[^1][^2]

Self-modifying or remotely loaded code shall not be used. Dynamically
loaded code other than dynamically linked libraries that are a standard
part of the platform shall not be used*.* Interpreted code shall not be
used unless it is created by an industry standard COTS compiler and
runtime interpreter (e.g. Java) and the version used is identified. This
prohibition is to ensure that the software tested and approved during
the qualification process remains unchanged and retains its integrity.

External modification of code during execution shall be prevented.

Where the development environment (programming language and development
tools) includes the following features, the software shall provide
controls on at least the following functions to prevent accidental or
deliberate attempts to replace or modify executable code, vote data, or
other sensitive targets:

a)  Arrays or strings with unenforced bounds (includes buffers used to
    move data);

```{=html}
<!-- -->
```
a)  Pointer variable errors;

b)  Dynamic memory allocation and management errors;

c)  Stack overflow errors;

d)  Run-time exception handling errors;

e)  Variables that are not appropriately handled when out of expected
    boundaries;

f)  Known programming language specific vulnerabilities.

[TO DO: Determine whether existing coding conventions for high-integrity
software can]{.mark} [subsume]{.mark} [the following.]{.mark}

If the software uses arrays or any analogous data structure and the
programming language does not provide automatic run-time range checking
of the indices, all accesses to these data structures shall occur via
accessor modules that range-check the indices. These range checks shall
comply with the general range checking requirements below.

All scalar or enumerated type parameters whose valid range as used in a
module does not cover the entire range of their declared data type shall
be range-checked on entry to the module. This applies to parameters of
character types, temporal types, and any other types for which the
concept of range is well-defined.

The failure to meet a range check condition shall be treated as a
complete failure of the module containing the range check. An
appropriate error and/or exception shall be generated and control shall
pass out of the module forthwith.

As range violations are incompatible with voting integrity, these checks
shall remain active in qualified production code, and the resulting
errors or exceptions shall require intervention by election officials.

The software shall provide controls to prevent any vote counter from
overflowing. Assuming that the counter size is large enough such that
the value will never be reached is not adequate. When the system can no
longer accept another ballot without compromising the integrity of the
counts, it shall emit appropriate warnings and audit events and cease to
enable or accept new ballots.

Requirements for ensuring that installed code on a target system is the
same as the tested and approved code are defined in [Section
XYZ]{.mark}.

-   
-   
-   

[]{#__RefHeading___Toc7170411 .anchor}Software Modularity and
Programming

Voting system application software, including COTS software, shall be
designed in a modular fashion. However, COTS software is not required to
be inspected for compliance with this requirement.. For the purpose of
this requirement[^3], "modules" may be compiled or interpreted
independently. Modules may also be nested. The modularity rules
described here apply to the component sub modules of a library. The
principle concept is that the module contains all the elements to
compile or interpret successfully and has limited access to data in
other modules. The design concept is simple replacement with another
module whose interfaces match the original module. A module is designed
in accordance with the following rules:

a.  Each module shall have a specific function that can be tested and
    verified independently of the remainder of the code. In practice,
    some additional modules (such as library modules) may be needed to
    compile the module under test, but the modular construction allows
    the supporting modules to be replaced by special test versions that
    support test objectives.

b.  

c.  

d.  constructed to be grouped according to functionality. No more than
    50% of all modules should exceed 60 lines of code (excluding
    comments) in length, no more than 5% of all modules should exceed
    120 lines in length, and no modules should exceed 240 lines in
    length. "Lines," in this context, are defined as executable
    statements or flow control statements with suitable formatting. The
    reviewer should consider the functional organization of the module
    and the use of formatting, such as blocking into readable units,
    which supports the intent of this requirement where the module
    itself, excluding comments, exceeds the limits. The vendor shall
    justify, to the satisfaction of the VSTL, any module lengths
    exceeding this objective.[^4][^5]

e.  Initializations of read-only lookup tables shall be exempt from
    length limitations. However, tables longer than 25 lines should be
    placed in separate files from other source code if the programming
    language permits it.

f.  

g.  

h.  

```{=html}
<!-- -->
```
1.  []{#__RefHeading___Toc7170412 .anchor}Control Constructs

Neither GoTo nor any semantically equivalent construct shall be used.

a.  
b.  
c.  

Unstructured exception handling (e.g., On Error GoTo, setjmp/longjmp)
shall not be used.

### 

### 

### 

### 

### 

### 

### Coding Conventions

The software shall consistently adhere to a published, credible set of
coding rules, conventions or standards (herein simply called "coding
conventions") intended to make source code more readable and
maintainable.

Coding conventions shall be considered published if they appear in a
publicly available book, magazine, or journal, or if they are publicly
available on the Internet.

Coding conventions shall be considered credible if at least two
different organizations with no ties to the creator of the rules or to
the vendor seeking qualification independently decided to adopt them and
made active use of them at some time within the three years before
qualification was sought.

If a VSTL requests it, the vendor shall furnish proof that the selected
coding conventions are published and credible.

Following are examples of coding conventions that are freely available
on the Internet as of 2005-02-17. These are only examples and are not
necessarily the best available for the purpose.

Java: "Code Conventions for the Java\[TM\] Programming Language," Sun
Microsystems. http://java.sun.com/docs/codeconv/

C++: "Programming in C++, Rules and Recommendations," Mats Henricson and
Erik Nyquist.
<http://www.chris-lott.org/resources/cstyle/Ellemtel-rules-mm.html>
(N.B., a revised and expanded version was published in Industrial
Strength C++, Prentice-Hall, 1996)

C#: "Design Guidelines for Class Library Developers," Microsoft.
http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp

a.  
b.  

[]{#__RefHeading___Toc7170415 .anchor}Comment Conventions

All modules shall contain header comments. Header comments shall provide
at least the following information:

1.  The purpose of the unit and how it works (if not obvious);

2.  

3.  A description of input parameters, outputs, exceptions thrown, and
    side-effects;

4.  File references by name and method of access (read, write, modify ,
    append, etc.);

5.  Global variables used;

6.  Date of creation; and

7.  Change log (revision record).

    The use of comments elsewhere in the module shall conform to the
    selected coding conventions.;

```{=html}
<!-- -->
```
a.  
b.  
c.  
d.  

```{=html}
<!-- -->
```
2.  []{#__RefHeading___Toc7170416 .anchor}Data and Document Retention

All systems shall:

a.  Maintain the integrity of voting and audit data during an election,
    and for at least 22 months thereafter, a time sufficient in which to
    resolve most contested elections and support other activities
    related to the reconstruction and investigation of a contested
    election; and

b.  Protect against the failure of any data input or storage device at a
    location controlled by the jurisdiction or its contractors, and
    against any attempt at improper data entry or retrieval.

## Audit Record Data

Audit trails are essential to ensure the integrity of a voting system.
Operational requirements for audit trails are described in Section
2.2.5.2 of the Standards. Audit record data are generated by these
procedures. The audit record data in the following subsections are
essential to the complete recording of election operations and reporting
of the vote tally. This list of audit records may not reflect the design
constructs of some systems. Therefore, vendors shall supplement it with
information relevant to the operation of their specific systems.

### Pre-election Audit Records

During election definition and ballot preparation,, the system shall
audit the preparation of the baseline ballot formats and modifications
to them, a description of these modifications, and corresponding dates.
The log shall include:

a.  The allowable number of selections for an office or issue;

b.  The combinations of voting patterns permitted or required by the
    jurisdiction;

c.  The inclusion or exclusion of offices or issues as the result of
    multiple districting within the polling place;

d.  Any other characteristics that may be peculiar to the jurisdiction,
    the election, or the polling place\'s location;

e.  Manual data maintained by election personnel;

f.  Samples of all final ballot formats; and

g.  Ballot preparation edit listings.

### System Readiness Audit Records

The following minimum requirements apply to system readiness audit
records:

a.  Prior to the start of ballot counting, a system process shall verify
    hardware and software status and generate a readiness audit record.
    This record shall include the identification of the software
    release, the identification of the election to be processed, and the
    results of software and hardware diagnostic tests;

b.  In the case of systems used at the polling place, the record shall
    include the polling place\'s identification;

c.  The ballot interpretation logic shall test and record the correct
    installation of ballot formats on voting devices;

d.  The software shall check and record the status of all data paths and
    memory locations to be used in vote recording to protect against
    contamination of voting data;

e.  Upon the conclusion of the tests, the software shall provide
    evidence in the audit record that the test data have been expunged;

f.  If required and provided, the ballot reader and arithmetic-logic
    unit shall be evaluated for accuracy, and the system shall record
    the results. It shall allow the processing, or simulated processing,
    of sufficient test ballots to provide a statistical estimate of
    processing accuracy; and

g.  For systems that use a public network, provide a report of test
    ballots that includes:

    1.  Number of ballots sent;

    2.  When each ballot was sent;

    3.  Machine from which each ballot was sent; and

    4.  Specific votes or selections contained in the ballot.

### In-Process Audit Records

In-process audit records document system operations during diagnostic
routines and the casting and tallying of ballots. At a minimum, the
in-process audit records shall contain:

a.  Machine generated error and exception messages to demonstrate
    successful recovery. Examples include, but are not necessarily
    limited to:

    1.  The source and disposition of system interrupts resulting in
        entry into exception handling routines;

    2.  All messages generated by exception handlers;

    3.  The identification code and number of occurrences for each
        hardware and software error or failure;

    4.  Notification of system login or access errors, file access
        errors, and physical violations of security as they occur, and a
        summary record of these events after processing;

    5.  Other exception events such as power failures, failure of
        critical hardware components, data transmission errors, or other
        type of operating anomaly;

b.  Critical system status messages other than informational messages
    displayed by the system during the course of normal operations.
    These items include, but are not limited to:

    1.  Diagnostic and status messages upon startup;

    2.  The "zero totals" check conducted before opening the polling
        place or counting a precinct centrally;

    3.  For paper-based systems, the initiation or termination of card
        reader and communications equipment operation; and

    4.  For DRE machines at controlled voting locations, the event (and
        time, if available) of activating and casting each ballot (i.e.,
        each voter\'s transaction as an event). This data can be
        compared with the public counter for reconciliation purposes;

c.  Non-critical status messages that are generated by the machine\'s
    data quality monitor or by software and hardware condition monitors;
    and

d.  System generated log of all normal process activity and system
    events that require operator intervention, so that each operator
    access can be monitored and access sequence can be constructed.

### Vote Tally Data

In addition to the audit requirements described above, other
election-related data is essential for reporting results to interested
parties, the press, and the voting public, and is vital to verifying an
accurate count.

Voting systems shall meet these reporting requirements by providing
software capable of obtaining data concerning various aspects of vote
counting and producing reports of them on a printer. At a minimum, vote
tally data shall include:

a.  Number of ballots cast, using each ballot configuration, by
    tabulator, by precinct, and by political subdivision;

b.  Candidate and measure vote totals for each contest, by tabulator;

c.  The number of ballots read within each precinct and for additional
    jurisdictional levels, by configuration, including separate totals
    for each party in primary elections;

d.  Separate accumulation of overvotes and undervotes for each contest,
    by tabulator, precinct and for additional jurisdictional levels (no
    overvotes would be indicated for DRE voting devices); and

e.  For paper-based systems only, the total number of ballots both
    processed and unprocessable; and if there are multiple card ballots,
    the total number of cards read.

For systems that produce an electronic file containing vote tally data,
the contents of the file shall include the same minimum data cited above
for printed vote tally reports.

## Vote Secrecy (DRE Systems)

All DRE systems shall ensure vote secrecy by:

a.  Immediately after the voter chooses to cast his or her ballot,
    record the voter's selections in the memory to be used for vote
    counting and audit data (including ballot images), and erase the
    selections from the display, memory, and all other storage,
    including all forms of temporary storage; and

b.  Immediately after the voter chooses to cancel his or her ballot,
    erase the selections from the display and all other storage,
    including buffers and other temporary storage.

[^1]: Portions of this section are derived from Section 5.6.2.2 of DRAFT
    P1583/D5.3.2b, 2005-01-04.

[^2]: This material is from an unapproved draft of a proposed IEEE
    Standard, P1583. As such, the material is subject to change in the
    final standard. Because this material is from an unapproved draft,
    the IEEE recommends that it not be utilized for any
    conformance/compliance purposes. It is used at your own risk.

[^3]: Some software languages and development environments use a
    different definition of module but this principle still applies.

[^4]: Modules shall be small, easily identifiable, and Portions of this
    paragraph are derived from Section 6.6.4.2, Paragraph i of DRAFT
    P1583/D5.3.2b, 2005-01-04.

[^5]: This material is from an unapproved draft of a proposed IEEE
    Standard, P1583. As such, the material is subject to change in the
    final standard. Because this material is from an unapproved draft,
    the IEEE recommends that it not be utilized for any
    conformance/compliance purposes. It is used at your own risk.