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

["Steve Knecht" <skglobal@earthlink.net>]

I think the statistical approach would be adequate, although the log with a
date and time stamp would be the preference.

I think that saving these for the 2.0 release is OK in the sense that we
might be able to "sell" the upgrade, vs having it be required.  However, it
might mean the AV would have to be recertified in many states.  Not good.
Other thoughts?
----- Original Message -----
From: Guy Lancaster <glanca@dieboldes.com>
To: Kerry Martin <kerry@dieboldes.com>
Cc: <rcr@dieboldes.com>
Sent: Thursday, December 09, 1999 8:40 AM
Subject: Re: Logging Scanner Jams (was: Audit trail improvement suggestions)


>   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
>
>