Re: Logging Scanner Jams (was: Audit trail improvement suggestions)

[Guy Lancaster <glanca@dieboldes.com>]

  Some form of logging scanner jams has been brought up
before and I think that I spoke with Steve about a month ago
about it.  This may also be related to Jane's RCR: Print
Vote Centers Activity of Oct 27, 1999.

  The problem, as Monica stated, is that the officials need
statistical support when trying to resolve discrepencies
between the number of ballots in the ballot box and the
number recorded by the Accu-Vote.  I can see three possible
ways of providing this, each with pros and cons.

1) Add a stats counter for the number of jams experienced
since the counters were last cleared.  While we're at it, we
could have separate counters for counted and returned ballot
jams.  This would be my preference since it provides the
required statistics while consuming the minimum of
resources. However it requires a memory card format change
and so would only be available in major new releases such as
the upcoming version 2.0.  These statistics would appear on
the audit reports and could be uploaded for reporting by
GEMS.

2) Print a log entry on the internal printer for each jam.
This could be selectively enabled and disabled from GEMS'
Accu-Vote parameters and would not affect the memory cards.
Downsides include having to prevent the tape from jamming
while it's locked in the printer compartment and having to
count the entries on the tape to gather the statistics.  The
upside is that it would provide a timestamp on each entry
which could help with resolving the problems.

3) Record an entry in the audit log for each jam.  This one
scares me a little because we have limited space on the
memory card for the audit log and currently we allow for
about 400 entries.  The purpose of the log is to record
critical operations such as inserting the memory card,
powering on the unit, the starting and ending of counting,
printing reports, and a few others.  Although possible, it
is very unlikely that we would overflow the audit log with
these entries.  Events like jams are far less predictable
and a problem with a machine could cause a large number of
jams.  Should the log overflow, the oldest entries are lost.

  Some would suggest that we increase the size of the audit
log or dynamically allow it to grow to use available memory
card space.  The latter is technically difficult especially
if we want to record events starting from the beginning of
the download operation as we do currently.  Allocating more
space for log entries comes at the expense of less space for
ballot information and counters which will affect those
counting absentee ballots.  It seems less of an issue for
128K memory cards than for 32K but once we decide to log
jams, we have to allow for it in all systems.

  My suggestion is to add support for optionally printing a
jam log message in the next 1.94 release.  For version 2, we
would continue to support this plus add statistics counters
for jams.  Unless people feel both that it is critical that
we record the time of each jam and that managing the printer
tape is not acceptable, I would avoid adding this to the
audit log.

           Guy