15
TGDC Meeting Presentation July 26 th , 2011 Ian S. Piper Director, Certification Dominion Voting Systems, Inc. [email protected] TGDC Meeting, July 2011

TGDC Meeting Presentation July 26 th, 2011 Ian S. Piper Director, Certification Dominion Voting Systems, Inc. [email protected] TGDC Meeting,

Embed Size (px)

Citation preview

TGDC Meeting Presentation

July 26th, 2011

Ian S. PiperDirector, Certification

Dominion Voting Systems, [email protected]

TGDC Meeting, July 2011

Next Steps on aCommon Data Format

A look at the Interoperability Use Case Draft

from IEEE P1622

TGDC Meeting, July 2011

Interoperability

• Interoperability has different meanings for different stakeholders.

• It’s important to establish a comprehensive overview of interoperability that provides a framework for developing a common data format.

• From that framework, certain implementation levels can be defined into which the elements of interoperability can be grouped.

TGDC Meeting, July 2011

3

Actors

TGDC Meeting, July 2011

4

Levels of Interoperability

1. Registered voter data, geo-political data, election definition data, blank ballot images, and election results data.

2. Ballot cast records, audit event logs, and ballot definition data (contests/candidates, but without specific ballot layout information).

3. Machine ballot definition data (with specific ballot layout information).

4. Machine configuration data.

TGDC Meeting, July 2011

5

Level 1 Interoperability

• Historically, data flows have been external to each system. EMS and VRS systems use import and export functions to transfer data between each other and to the State level systems (SES), VRS and EPB use similar functions between each other, and EMS exports blank ballot images for BBDS. However, each system has its own format that requires translation into each of the other systems’ formats.

• As these systems already have the capacity to interoperate through those import/export functions, it should be feasible for existing systems to be modified to transfer data in a format that complies with this level of interoperability.

TGDC Meeting, July 2011

6

SESState Election

Systems

VRSVoter Reg Systems

BBDSBlank Ballot Dist Systems

EMSElection Mgmt

Systems

Geo-political

Election Definition

Registered Voters

Geo-political

Election Definition

Results Reporting

Blank Ballot Images

Geo-political

Election Definition

# Registered Voters

Voter Turnout

Level 1 Data

TGDC Meeting, July 2011

EMSElection Mgmt

Systems

EPBElectronic Poll

Books

Geo-political

Registered Voters

Voters who voted

Geo-political

Election Definition

7

Level 2 Interoperability

• On a lower level, an EMS can provide data to other external systems, such as:

– audit event logs, ballot cast records and election results to Audit Management Systems (AMS), and

– ballot contest data to Blank Ballot Distribution Systems (BBDS).

• In addition to a common data format for audit logs, it would also be beneficial to have a common lexicon for audit log entries through which an analysis of an audit log can be done more efficiently and effectively.

TGDC Meeting, July 2011

8

BBDSBlank Ballot Dist Systems

EMSElection Mgmt

Systems

Contests and Candidates per Ballot Style

Level 2 Data

AMSAudit Mgmt

Systems

Audit Event Logs

Ballot Cast Records

Results Reporting

TGDC Meeting, July 2011

9

Level 3 Interoperability

• On an underlying level within the EMS, the machine ballot definition data could be provided to BBDS systems. This information can be broken out into three segments that represent the type of ballot output from the BBDS.

A. Non scan-able ballot.

B. Scan-able ballot

C. Scan-able ballot with required formatting.

• Note that the ability to generate a ballot that a VCD can scan depends on the BBDS printer being capable of producing a ballot that meets the VCD’s ballot specifications.

TGDC Meeting, July 2011

10

BBDSBlank Ballot Dist Systems

EMSElection Mgmt

Systems

Segment A

Ballot not scan-able by VCD, but with ordered contests, endorsements, rotations, straight party/recall contest associations, and ballot/precinct IDs.

Level 3 Data

Segment B

Scan-able ballot with Segment A elements plus shape/size/color/position of voting targets, timing marks, control marks and special marks.

Segment C

Scan-able ballot with Segment B elements plus required font type/size/color, background color, watermark, color striping, and instructional text.

TGDC Meeting, July 2011

11

Level 4 Interoperability

• At the base level within the EMS, the machine configuration data that is downloaded to the VCDs could be provided to VCDs from other voting systems. This information would provide all the detail required for the machine’s operation.

• At this level of data interchange, one EMS could create memory devices for the VCDs of another EMS.

• Although the data on the downloaded memory devices would be interchangeable between VCDs, for election integrity, an EMS would only allow the upload of memory devices it has created.

TGDC Meeting, July 2011

12

EMSElection Mgmt

Systems

Level 4 Data

VCDVote Capture

Devices

VCDVote Capture

Devices

EMSElection Mgmt

Systems

TGDC Meeting, July 2011

13

Machine configuration data would include:

•Memory media ID

•Election header information

•Security and verification data

•Election data

•Rejection criteria

•Ballot sorting options

•Cast vote records

•Tally results counters

•Modem upload phone number

•Audit logs

Level 4 Data

For DRE interface devices, the data would also include:

•Header/footer sizes, number of columns, scaling factors

•Button type/size/position/justification

•Flags for voting, rendering, text wrapping

•Background colors for pages/labels/contests/candidates

•Instructional text, write-ins, audio, and default volumes

TGDC Meeting, July 2011

14

TGDC Meeting, July 2011