This is an HTML version of an attachment to the Freedom of Information request 'Audit documents for the 2020 EVACS system'.


 
Elections ACT 
Upgrade of eVACS® for the 2020 
ACT Legislative Assembly Election 
 
Operational Concept Description 
 
Document Status: Final 
Version 1.1 
December 2019 
 
 
 
 
 
 
 
 
 

Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 2 
Copyright Notice 
Copyright Software Improvements Pty Ltd 
This document has been produced by Software Improvements Pty Ltd on behalf of the ACT Electoral 
Commission (Elections ACT). 
This document is the property of Elections ACT who shall retain its copyright jointly with Software 
Improvements Pty Ltd.  It may not be reproduced or recorded in whole or part in any form or media 
without the explicit written approval of Elections ACT. 
Disclaimer 
In compiling this Operational Concept Description document, Software Improvements Pty Ltd has 
relied upon the accuracy and completeness of information provided by Elections ACT.  
eVACS® 
eVACS® is a registered Trade Mark of Software Improvements Pty Ltd. 
Where used in this Operational Concept Description, eVACS has the same meaning as eVACS® 
eVACS® Upgraded Documentation Tree 
 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 3 
Document Control Information 
The control ed version of this document is in electronic form. 
Al  hardcopy versions are uncontrolled.  
Modifications 
Date of this 
Version  Comment 
Author 
Reviewer  Release 
Revision 
2019-08-04 
0.1 
Initial Draft 
CVB 
CJB 
 
2019-08-12 
0.2 
Expanded Draft 
CJB 
RB 
 
2019-09-09 
0.3 
IVR content revised and extended 
CJB 
JS 
 
2019-11-15 
0.4 
Revised following comments from EACT 
CJB 
 
 
2019-12-26 
1.0 
Amended to reflect changes in voting sequence 
CJB 
 
2019-12-30 
and touch screen operations, and includes 
description of new report for LAPPERDS 
Distribution 
Name and Appointment 
Document Name 
Date of Issue 
Version 
Rohan Spence, DEC, EACT 
Operational Concept Document 
2019-09-09 
0.3 
Jiv Sekon, Project Manager, EACT 
Rohan Spence, DEC, EACT 
Operational Concept Document 
2020-02-14 
1.0 
Jiv Sekon, Project Manager, EACT 
 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 

link to page 2 link to page 2 link to page 2 link to page 2 link to page 3 link to page 3 link to page 3 link to page 4 link to page 6 link to page 6 link to page 6 link to page 6 link to page 6 link to page 8 link to page 8 link to page 8 link to page 8 link to page 9 link to page 9 link to page 10 link to page 10 link to page 10 link to page 10 link to page 11 link to page 12
 
 
Operational Concept Description 
 
 
Page 4 
Contents 
COPYRIGHT NOTICE ............................................................................................ 2 
Disclaimer ........................................................................................................................................... 2 
eVACS® ............................................................................................................................................. 2 
eVACS® Upgraded Documentation Tree........................................................................................... 2 
DOCUMENT CONTROL INFORMATION .............................................................. 3 
Modifications ....................................................................................................................................... 3 
Distribution .......................................................................................................................................... 3 
CONTENTS ............................................................................................................ 4 
1.  INTRODUCTION ............................................................................................ 6 
1.1  Overview .................................................................................................................................. 6 
1.2  Document Purpose ................................................................................................................... 6 
1.3  Document Management ........................................................................................................... 6 
1.4  Reference Documents.............................................................................................................. 6 
2.  CURRENT EVACS® ...................................................................................... 8 
2.1  Background .............................................................................................................................. 8 
2.2  Operational policies and constraints ........................................................................................ 8 
2.3  Description of current eVACS® ................................................................................................ 8 
2.3.1 
Election setup ....................................................................................................................... 9 
2.3.2 
Electronic voting ................................................................................................................... 9 
2.3.3 
Paper bal ots ...................................................................................................................... 10 
2.3.3.1 
Data entry of paper bal ots ............................................................................................. 10 
2.3.3.2 
Scanning of paper bal ots ............................................................................................... 10 
2.3.4 
Counting and reporting ...................................................................................................... 10 
2.4  Design and security ................................................................................................................ 11 
3.  JUSTIFICATION AND NEED FOR CHANGES ........................................... 12 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 

link to page 12 link to page 12 link to page 16 link to page 16 link to page 17 link to page 17 link to page 17 link to page 18 link to page 18 link to page 18 link to page 18 link to page 19 link to page 21 link to page 21 link to page 22 link to page 22 link to page 23 link to page 24 link to page 24 link to page 24 link to page 24 link to page 25 link to page 25 link to page 27 link to page 28
 
 
Operational Concept Description 
 
 
Page 5 
3.1  Justification for changes ......................................................................................................... 12 
3.2  Description of changes ........................................................................................................... 12 
4.  CONCEPT FOR UPGRADED EVACS® ...................................................... 16 
4.1  Background, objectives and scope ........................................................................................ 16 
4.2  Operational policies and constraints ...................................................................................... 17 
4.2.1 
Constraints on electronic voting ......................................................................................... 17 
4.2.2 
Constraints on electronic vote counting ............................................................................. 17 
4.3  Description of the upgraded system ....................................................................................... 18 
4.3.1 
The operational environment and its characteristics ......................................................... 18 
4.3.2 
Major system components ................................................................................................. 18 
4.3.3 
Interfaces to external systems or procedures .................................................................... 18 
4.3.4 
Capabilities/functions of upgraded eVACS® ..................................................................... 19 
4.3.5 
Performance characteristics .............................................................................................. 21 
4.3.6 
Quality attributes ................................................................................................................ 21 
4.3.7 
Provisions for security and recovery .................................................................................. 22 
4.4  User/affected personnel ......................................................................................................... 22 
4.5  Support and maintenance ...................................................................................................... 23 
5.  OPERATIONAL SCENARIOS ..................................................................... 24 
5.1  Electronic voting ..................................................................................................................... 24 
5.1.1 
Touch screen voting ........................................................................................................... 24 
5.1.2 
Keypad with audio voting ................................................................................................... 24 
5.1.3 
Telephone voting ................................................................................................................ 25 
5.2  Paper bal ot entry ................................................................................................................... 25 
ANNEX A: FORMAT OF FILE FOR UPLOAD TO LAPPERDS .......................... 27 
ANNEX B: GLOSSARY ....................................................................................... 28 
 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 6 
1.  Introduction 
1.1  Overview 
Elections ACT (EACT) is responsible for conducting elections and referendums for the ACT 
Legislative Assembly, and maintaining the ACT electoral roll.  EACT is a Statutory Authority and is 
responsible for providing ACT citizens with an independent electoral service that meets their needs 
and enhances their understanding of, and participation in, the electoral process.  
Electronic voting at selected pol ing places in the ACT was first introduced at the 2001 Legislative 
Assembly election, using the electronic voting and counting system known as eVACS®.  Minor 
upgrades and enhancements were implemented for later Legislative Assembly elections, but following 
a review after the 2016 Legislative Assembly election eVACS® is now to be enhanced to provide an 
updated system with increased functionality and features.  In particular, eVACS® is to be moved to a 
more contemporary platform, with improvements in security, and inclusion of a secure telephone 
voting module.   
1.2  Document Purpose 
This Operational Concept Description (OCD) describes at a high level the desired enhanced version of 
eVACS®, that during the development phase wil  be referred to as ‘eVACS® Upgrade’.  The structure 
of the document is as follows.  First, the background and structure of the existing version of eVACS® 
is described.  Second, a summary of the desired enhancements is given. Third, the two preceding 
sections are consolidated to give a self-contained – but still high-level – description of the desired 
enhanced eVACS® Upgrade system.  
The purpose of this document is to provide the Software Improvements Pty Ltd (SIPL) Project Team 
with a specification of the requirements of the eVACS® Upgrade.  The OCD wil  form the basis from 
which system requirements wil  be developed.  The resulting System/Subsystem Specification wil  
then form the basis for developing a detailed Software Requirements Specification and Interface 
Requirements Specification (IRS) documents. 
1.3  Document Management 
The OCD will be reviewed and amended, if required, at the first major milestone of the project.  The 
eVACS® Upgrade Project Manager is responsible for this review in conjunction with the EACT Project 
Manager, and for ensuring all project personnel are advised of any variations.  Any significant changes 
to this OCD should be reviewed and approved by the EACT Project Manager or nominated delegate.  
1.4  Reference Documents 
Documents referenced in this OCD include:  
1.  Business Requirements Specification ICT Business System upgrade - eVACS®, version 1.0; 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 7 
2.  Contract – Electronic Voting and Counting System (eVACS®) Enhancements, Services and 
Support: ACTGS reference 636238 Final Version 23 July 2019, including the Statement of 
Requirements at Schedule 2 being a modified version of the Business Requirements 
Specification;  
3.  Unified Modeling Language (UML) Specification - Version 2.5, May 2015.  Object Management 
Group (OMG) website - https://www.omg.org/spec/UML/2.5;  Sections 11.6 (Components) and 
10.4 (Interfaces) are typical y used to describe high level views of systems. 
4.  Executable UML: A Foundation for Model-Driven Architecture by S. Mellor & M. Balcer, 2002 
(Addison Wesley).  Chapters 3 and 15 provide description of Domain Charts and Domain 
Verification as part of the Executable UML methodology for constructing and executing models, 
which are constructed using a large subset of UML 2.5.  Domain Charts are a precursor to 
Component Diagrams (now standardised in UML 2.5) 
5.  BridgePoint (BP) 6.1 Style Guide to xtUML Modeling, 2011 (from BP Help System).  BP is an 
open source toolset that supports Executable UML and is maintained under the banner of 
xtUML.org on the world-wide web (WWW). 
6.  BridgePoint 6.1 The xtUML Modeling Guide, 2011 (from BP Help System). 
7.  Guide to the preparation of operational concept documents ANSI/AIAA G-043A-2018 
8.  Safe and Secure Software – updated for SPARK 2014, John Barnes, 2015, AdaCore  
9.  ISO/IEC 8652 Information Technology – Programming Languages – Ada, 3rd edition December 
2012 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 8 
2.  Current eVACS® 
2.1  Background 
For the October 2001 ACT Legislative Assembly election EACT introduced a non-Internet electronic 
voting within four pre-pol  centres around Canberra for two weeks prior to Election Day and at a 
number of pol ing places on Election Day.  A computer program on a separate ‘counting’ server 
allowed the upload of data from electronic votes or manual data entry of paper bal ots in order to count 
all votes according to the Hare-Clark rules of the ACT. 
SIPL provided the software (known as eVACS®) for voting and counting for the 2001 and 2004 ACT 
Legislative Assembly elections and the Casual Vacancies that occurred between those two elections.  
For the 2008 Legislative Assembly election, EACT introduced scanning of paper ballots, and eVACS® 
was modified to enable the upload of electronic vote data from the scanning process.  Scanning of 
paper bal ots has continued to be used in all subsequent elections up to 2016. 
2.2  Operational policies and constraints 
The ACT has a relatively complex electoral system. The system used is the Hare-Clark single 
transferable vote system of proportional representation.  Currently the Legislative Assembly comprises 
25 members, with 5 members being elected to represent each of 5 electorates.  The ACT voting 
population is approximately 300,000 electors.  The ACT has fixed term elections, original y every three 
years, but from 2004 at four-year intervals.  The next Legislative Assembly election is in October 2020. 
(More details about the ACT voting system are available on the EACT website 
https://www.elections.act.gov.au.) 
To vote, electors are asked to number candidates in the order of their preferences, using sequential 
numbering starting with ‘1’ being their most preferred.  Candidates are listed on the bal ot paper in 
columns, with registered political parties and non-registered party groups given their own column.  
Independent candidates are listed together in one or more columns. 
The order of the candidates’ names in each column is changed from one ballot paper to another using 
a system called Robson Rotation.  This aspect of the voting system gives candidates equal chances to 
be at the top of their particular column across all variations (60 for 5 member electorates) of the ballot 
paper.  Voters must vote for candidates; they do not have the option of voting for parties. 
A bal ot is considered formal if there is a first preference indicated.  The voting instructions 
recommend voters give at least as many preferences as there are seats in the electorate, and then as 
many further preferences as desired. 
2.3  Description of current eVACS® 
The fol owing is a broad view each of the five modules forming the electronic voting and counting 
system as operated in the ACT: 
•  Election setup 
•  Electronic voting 
•  Data entry of paper bal ots 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 9 
•  Counting ,and  
•  Reporting 
2.3.1 Election setup 
The fol owing information is input by officials into the setup server: 
•  Election name and date 
•  Names of electorates 
•  Details of pre-pol  and polling places, including batch numbers for paper ballots 
•  Names of parties fielding candidates for the election 
•  Names of candidates, arranged by electorate and by party 
•  Names of candidates who are ungrouped – who do not belong to any of the parties, arranged 
by electorates 
•  The form of the ballot papers 
The setup server generates the voting server software, including operating system, that is loaded on 
to hardware to create the voting server at each polling place, referred to as the pol ing place server. 
2.3.2 Electronic voting 
The voting client presents voters with the ability to select instructions in their language of choice 
selected from English and a number of additional languages which may change between elections 
depending on the use of those languages within the community.  For example, in 2016 the languages 
which could be selected were: 
•  Arabic 
•  Chinese – Simplified (Mandarin) 
•  Croatian 
•  Greek 
•  Italian 
•  Korean 
•  Lao 
•  Persian / Farsi 
•  Portuguese 
•  Serbian 
•  Spanish 
•  Vietnamese 
Voters with disabilities are also able to use the system, for example, instructions through earphones 
are provided to voters with vision-impairment.  To date, audio instructions have only been available in 
English. 
Those voters who decide to vote electronically are issued with a barcode by a pol ing official who also 
marks their name on the electoral rol .  The barcode is used to verify to the voting interface that the 
voter has a right to vote in a particular electorate.  At the voting booth, instructions on how to vote are 
displayed.  Several levels of help are available. 
The voter begins the voting process by having their barcode read a first time.  If the barcode is 
accepted, a full view of the ballot paper for their specific electorate is displayed. 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 10 
Using a telephone-style keypad, the voter selects their candidates in preference order.  When each 
candidate is selected, the next sequential preference number is displayed (or announced via audio).  
A voter is able to choose not to vote for any candidates - thus making an informal vote.  Options to 
cancel a preference or begin again are provided.  There is also an option to ‘hide’ their vote if a voter 
needs to seek help from an official.  When the voter selects the ‘Finish’ (#) key, the voter is required to 
have their barcode read a second time to confirm their selection of candidates.  The system provides 
security that wil  allow the voter to cast only one vote per barcode. 
After the vote has been confirmed, voting data is stored initially in two locations. 
After polling closes first preference distributions are calculated before all the voting data is transferred 
to the vote counting system via removable WORM disks.  Data is protected by an MD5 checksum and 
two randomly generated 128-bit keys.  The daily cumulative voting data is also transferred with the 
same securities in place. 
2.3.3 Paper bal ots 
For those electors who vote using a paper bal ot the voting procedures remains unchanged.  Voters 
are asked to mark sequential preferences on their bal ot paper up to the number of seats to be fil ed 
for their electorate, or for as many more candidates as they desire.  A single ‘1’ marked on a ballot 
paper is considered a formal vote.  The bal ot paper is then folded and deposited in a cardboard ballot 
box. 
2.3.3.1  Data entry of paper ballots 
At the close of the poll, at each pol ing place the lodged paper ballots are unfolded and counted to first 
preferences and bundled into batches according to the candidate for whom the voter’s first preference 
is indicated.  These bundles form the basis of the batches to be entered into the vote database.  
Following first preference results being reported, the ballot papers are transferred to a central location 
where they are manual y entered into the vote database.  The paper bal ots are keyed in the batches 
as compiled at the pol ing places. Each bal ot paper is keyed by two operators as a way of verifying 
operators’ input; a supervisor resolves any differences. 
2.3.3.2  Scanning of paper bal ots 
Since 2008, paper bal ots for scanning are unfolded, first preferences counted and then bundled into 
batches.  As per the data entry procedures, following first preference results being reported, the ballot 
papers are transferred to a central location where they are scanned.  Once any unreadable papers 
have been examined, the electronic vote data is exported and imported into the eVACS® counting 
system. 
2.3.4 Counting and reporting 
The vote counting program enables an automatic Hare-Clark scrutiny for the election.  The program 
calculates preference distribution results using data obtained through electronic voting and electronic 
vote data obtained from paper bal ots to provide progressive reporting from election night onwards.  
The results are presented as scrutiny and distribution sheets. 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 11 
2.4  Design and security 
A range of security features were built into the design of eVACS® in 2001, and these are inherent in 
the 2016 version.  They are: 
•  a non-Internet solution, being a secure ethernet-based LAN at each polling place 
•  both voting and data entry terminals being equivalent to dumb terminals with no data stored 
on them 
o  voting access is barcode controlled 
o  data entry access is password protected 
•  a server at each pol ing place with physical protection, authorised access controls, duplicate 
hard drives, and only menu driven functionality 
•  any existing software or operating system on any of the hardware is removed as part of the 
instal ation process for eVACS® software modules 
•  any vote data transferred from polling places is protected with an MD5 checksum and two 
randomly generated 128-bit keys 
•  all printouts, such as scrutiny sheets, are printed directly with PostScript and cannot be 
altered 
•  counting and data (voting and data entry) servers with only authorised access and menu 
driven functionality  
•  only authorised software can be used for an election, and the software for pol ing servers is 
generated by the election set-up server, and 
•  the operating system is a cut down version of Linux, only supporting the functions required by 
eVACS®. 
eVACS®, as used in 2016, is written in the ‘C’ language and, as mentioned above, the operating 
system is a cut down version of Linux.  During the years since 2001 the operating system has been 
upgraded, although currently is not the latest version. 
 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 12 
3.  Justification and need for changes 
There are two main concerns driving the need for changes in eVACS®: 
•  Modernisation of the underlying technologies and hardware, including security, and 
•  Improved usability and accessibility for voters 
3.1  Justification for changes 
Following independent review of eVACS® after the 2016 Legislative Assembly election, together with 
concerns raised by Members of the Legislative Assembly, the fol owing are being addressed via the 
proposed upgrade: 
•  modernisation of the underlying technologies and hardware 
o  currency of operating system 
o  more appropriate language with better security and functionality features 
o  absence of modern-day management and security protocols (such as database 
encryption) 
o  system not meeting compatibility requirements of modern hardware 
•  improved usability and accessibility 
o  out-of-date screen displays 
o  replacement of keypads for navigation (touch screens for non-B&VI electors) 
o  an alternative secret voting process for electors who have difficulty in attending pol ing 
places (telephone voting module) 
A number of other improvements to the processes of installing and operating eVACS® have also been 
identified for inclusion in the upgrade. 
3.2  Description of changes 
The changes required can be summarised as follows: 
Access passwords – to be accepted a password to meet ACT Government and ASD password 
security standards. 
Audio – .WAV files to be used. 
 
Audio files to be nested for easy identification of individual files by EACT staff 
Autonomy – no details of an election to be hard coded into the software.  Configuration of the system 
is to be possible with specific inputs as part of tailoring the system for a particular election.  
Such tailoring is to continue to be carried out by EACT staff without the need for intervention of 
SIPL staff. 
Bal ot layout – the layout of electronic bal ots is currently fixed.  As part of the setup process, the 
format of a bal ot paper to be customisable for an election, including configuration of: 
i) 
font size for candidate names 
ii) 
font type, size and placement of text. 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 13 
Ballot rotations - eVACS® allows for Robson Rotations based on 5 and 7 member electorates, 
although currently al  electorates have only 5 members.  Flexibility in having different numbers 
of members should not be deleted from the system; this includes allowing for input of number of 
members and the associated rotation sequences.  
Barcodes– 1D barcodes used by voters to be replaced with 2D barcodes (QR codes).   
 
Official, or master QR code, to be introduced for use by officials to access new menu for 
selection of appropriate reset options on voting clients with touch screens. 
 
QR codes able to be prepared as postscript file for provision to contracted printer, as well as 
ready-for-printing inhouse. 
 
Convert SHA-2 encrypted hash code output to QR code at polling place server to be read as 
input to election sever when uploading vote data.  
Counting – provide for the calculation of vote values rounded down to 6 decimal places. 
 
Counting to be based on Ada 2012 and stored procedures.   
Data entry of paper bal ots - the data entry module of eVACS® to continue to be operational; 
however, as EACT considers the likelihood of use to be very remote, the ‘C’ data entry module 
is not to be rewritten but simply integrated into the modernised eVACS®.  
Error codes – error codes to have a direct reference to the exact nature of the error.  The nature of 
error and resolution actions to be detailed in system documentation. 
Hardware – dependencies on particular hardware configuration items to be minimised, for example, 
the existing eVACS® places requirements on the choice of printers. 
Incorporation of touch screens for voting, noting that the use of a setup with a telephone-style 
keypad and audio instructions wil  continue to be available at each polling place for B&VI 
electors. 
Unused ports on hardware at pol ing places to be decommissioned via the operating system. 
Polling place and telephone voting servers to be capable of supporting printing of reports, hence 
the connection of a printer. 
The absence of disk readers in modern hardware, challenges the continued use of WORM 
disks for instal ation of software on hardware and the transfer of data.  Hence, disks to be 
replaced with secure USB memory sticks that support encryption of contents. 
Multiple languages – the interfaces used by voters to be based on Unicode text and available in 
multiple languages, where the number and specific languages to be used can vary between 
elections. 
Unicode text also to be used for al  interfaces used by officials and the reports generated by the 
system. 
Multiple pol ing place servers – currently the polling place servers, one per electorate, are created 
by loading a voting server installation created by the election setup server.  This manual 
process is to be replaced with an automatic load process using an isolated LAN connected to 
the election setup server.  As part of the installation process, automatic testing to ensure correct 
operation of the server is to be implemented. 
Identification of the pol ing place of a particular voting server is to be undertaken after delivery to 
the polling place. 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 14 
Multiple voting clients – each pol ing place has multiple identical voting clients connected via a LAN 
to the pol ing place server.  The manual process of installing the voting client software onto 
hardware to be replaced with an automatic load and test process from the pol ing place server. 
Network encryption – eVACS® currently uses http for communications across the LAN at each 
polling places.  Update to https (currently based on TLS1.2) to ensure al  these communications 
are encrypted. 
Printing – In addition to scrutiny sheets, new reports to be printed include: 
i) 
first preference count for each polling place and telephone voting after close of polling on 
Election day 
ii) 
reports of errors, votes not concluded, languages used, and use of B&VI system printed 
individually and collectively 
iii) 
SHA2 hash in QR code form in association with daily export of votes at pol ing places 
iv) 
Scrutiny sheet preference tracking report 
Privacy – ensure no potential link between voter and their vote by eliminating any timestamp 
associated with a vote, shuffling votes within votes database on polling place server and 
encrypting votes with SHA-2 algorithm. (see also Vote data encryption) 
Reports – the format of scrutiny sheets and other generated reports is currently fixed.  The reporting 
software to be flexible enough to support a variety of different types of reports, noting that a 
number of additional reports are required: 
i) 
frequency of types of error code experienced during polling 
ii) 
number of electronic votes commenced but not concluded 
iii) 
number of occurrences of selection of each language other than English 
iv) 
number of occurrences system accessed by B&VI electors 
v) 
‘result of count’ (first preference count) undertaken after close of pol ing on Election day 
to be printable 
vi) 
report for import into LAPPERDS (see Appendix B for file format) 
vii) 
Scrutiny sheet preference tracking report 
Scanning of paper bal ots – scanning of paper bal ots to continue outside of eVACS®.  The 
electronic vote data obtained from scanning to continue to be imported into eVACS®. 
Setup procedure – the existing eVACS® setup server comes with certain database tables already 
created; these tables to be created from data entered during the autonomous election setup 
procedures. 
 
The change to daylight saving occurs during the pre-pol  period for ACT Legislative Assembly 
elections.  Date of change to be incorporated into required setup election data so that servers 
can automatical y change the date during operations. 
 
To support testing of the system, provide for the resetting of the date and time without needing 
to adjust the settings in the BIOS. 
Software – Al  existing functionality to be migrated from ‘C’ to Ada 2012, with SPARK used to ‘prove’ 
the integrity of the software. 
 
Provide for a version of the source code easily publishable on the Elections ACT website, as 
well providing to an independent code auditing company. 
 
Provision of a transparent and control ed mechanism for recovering data from a failed hard 
drive. 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 15 
Telephone voting server – incorporation of a telephone voting module requires inclusion of a 
telephone voting server.  Although similar in purpose to a polling place server, because 
additional functionality is required, a separate telephone voting server installation and creation 
via the setup election server is necessary. 
Vote data encryption – vote data to be encrypted in the polling place server database using SHA-2 
algorithm and when exported.   
Vote reconstruction – as part of confirming a vote, the current voting client sends to the voting server 
not only the list of preferences but also the list of keystrokes used to construct the vote.  The 
voting server then ‘reconstructs’ the vote using the keystrokes and compares it with the list of 
preferences.  Only if there is a match is the vote confirmed. (A failure to match should never 
occur.)  This checking to be continued for the B&VI booth at the pol ing centres. 
 
With the introduction of touchscreens for voting, where used the list of keystrokes to be 
replaced with a list of screen touches for comparison with the preferences list.   
Vote transfer – vote data to be encrypted for transfer from polling place server to election server, with 
mandated entry of ‘hash code’ before upload to election server possible. 
Voting – display a particular coloured screen for an agreed period of time to visual y indicate that an 
elector has successfully finalised the casting of their vote. 
 
Preference box and candidate name to be a single touch element on touch screens. 
 
 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 16 
4.  Concept for upgraded eVACS® 
Encompassed in this section is a description of all the elements to comprise the upgraded eVACS®. 
4.1  Background, objectives and scope 
The scope of the upgraded eVACS® is essentially the same as eVACS® but with an additional 
module to support telephone voting.  The latter, to provide specifically an alternative to enable electors 
with a disability and blind and vision impaired electors who have difficulty attending a polling place to 
vote in secret. 
As indicated in section 3, a key objective of the eVACS® upgrade is modernising the system and its 
development.  To that effect the system is to be: 
i) 
model ed and the model used to autogenerate code, thereby reducing the potential for 
coding errors and the testing time during development of components 
ii) 
migrated to Ada 2012 using SPARK, which is used for the development of high integrity 
systems where predictable and highly reliable operation is essential 
Improved security is another key objective, but without diminishing the existing in-built security 
features, by: 
o  Ensuring only audited software is used for an election, and the software for different 
modules is generated by and installed via the election setup server 
o  Only menu driven functionality is available, with some access controlled via official 
(master) QR codes  
o  Maintaining a LAN at each polling place but moving from http (without encryption) to 
https (with encryption) for all communications between voting clients and the pol ing 
place server 
  https also to be used for communications between the telephone voting 
server and the IVR system 
o  Moving from one dimensional (1D) barcodes to 2D barcodes (QR codes) for 
accessing the voting clients at polling places 
o  Ensuring vote data is encrypted in the database and when being transferred from 
polling places 
o  Moving from MD5 and 128-bit security to SHA-2 algorithms  
o  Mandating the entry of security on the election server when vote data is being 
uploaded 
o  Implementing ACT government approved length passwords whenever passwords are 
used 
o  Using two-factor authentication for telephone voters 
o  Physically limit the availability of ports on voting server hardware 
A third key feature is improving accessibility via: 
•  adoption of touch screens, and 
•  introduction of telephone voting. 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 17 
4.2  Operational policies and constraints 
For use in any Legislative Assembly election the upgraded eVACS® must comply with the relevant 
legislation and other regulations.  Such legislation governs: 
•  The format of bal ots: order and arrangement of columns and rows 
•  Rotation of candidates on a ballot 
•  What constitutes a formal ballot 
•  What types of informal ballots can be accepted 
•  Counting procedures 
•  Reporting  
The fol owing high-level constraints – non-functional requirements – include many carried over from 
the current eVACS®. 
4.2.1 Constraints on electronic voting 
•  The system shal  allow input of preferences using a standard telephone style keypad. 
•  The system shal  ensure that two copies of the electronic voting data are recorded in separate 
locations within the pol ing place immediately a vote is cast and confirmed by the voter. 
•  The system shal  provide for the transfer of electronic voting information (not via the Internet 
or any publicly accessible network) from voting at pre-poll centres at the end of each pre-
polling day and polling places at the end of pol ing on polling day to the vote counting system.  
•  The system shal  not be connected to any outside network in any of the pre-pol  centres, 
electronic-voting equipped polling places, and the central scrutiny centre so that unauthorised 
access to the system is prevented. 
•  While the telephone voting server must be connected to the IVR servers supporting telephone 
connection, the telephone voting server must be located in a secure environment and setup 
such that the only communications are via https to the IVR servers. 
•  The electronic voting interface shall incorporate recorded spoken instructions in English 
broadcast over disposable headphones for sight impaired people and for people with reading 
difficulties. 
4.2.2 Constraints on electronic vote counting 
•  Configuration information to provide for a complete backup of data relayed to or captured by 
the system shal  be provided. 
•  The system shal  be capable of amendment to cater for enhancement and legislation 
changes. 
•  The system shal  allow programming code to be independently audited and be available to 
scrutineers for verification and to ensure “what goes in is what comes out”. 
•  The system shal  be secure and once the code is verified and audits are complete code 
should be certified and locked so no further changes can be made. 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 18 
4.3  Description of the upgraded system 
4.3.1 The operational environment and its characteristics 
The operational environment is substantially unchanged from the previous releases of eVACS. 
The upgraded eVACS® requires the fol owing hardware components: 
•  PCs for servers capable of running Linux, includes election setup server, polling place servers 
and telephone voting server, and servers running Windows for the telephone IVR servers 
•  Printers (for printing 2D barcodes for testing and reports) 
•  All-in-one PCs with touch screen for voting clients at polling places 
•  PC for B&VI voting booth at each polling places, if all-in-one PC is not suitable 
•  Telephone-style keypads (for all B&VI voting booths at polling places) 
•  2D barcode readers (for voter authentication and for official access to menus on the voting 
clients, pol ing place servers, telephone voting server and the Election server) 
•  Headphones (for use by vision-impaired voters) 
4.3.2 Major system components 
Upgraded eVACS® includes the fol owing software components: 
•  Election setup server (one instance) 
•  Electronic voting client (many instances per polling place) 
•  Electronic voting server (one instance per pol ing place) 
•  Electronic telephone voting server (one instance) 
•  Paper bal ot entry client (many instances) 
•  Counting and reporting server (one instance; including paper bal ot entry server) 
The components interact as follows: 
•  Al  information concerning the election is entered into the election setup server, which is used 
to generate installations for voting servers (polling place and telephone), and combined paper 
ballot entry/counting and reporting servers. 
• 
Al  instances of the voting client are identical. Al  instances of the voting (polling) place server 
are identical. 
•  Each group of electronic voting clients installed in a pol ing place communicates with the 
electronic voting server installed at that polling place. 
•  Al  instances of the paper ballot entry client are identical.  Each paper bal ot entry client 
communicates with a paper ballot entry server. 
•  The telephone voting server interacts with the IVR component of the telephone voting system. 
4.3.3 Interfaces to external systems or procedures 
Paper bal ots 
A combination of electronic voting and paper ballots is permissible.  Each paper ballot should have the 
number of the rotation printed on it; this number is entered during paper ballot entry so that the same 
ballot paper can be displayed for use by the DEO.  
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 19 
In eVACS®, paper ballots are batched into lots of 50 for data entry. Each batch is assigned a unique 
identifier composed of the electorate, pol ing place, and batch number for that polling place.  
At the end of pol ing, officials empty the ballot boxes, group the paper bal ots by first preferences and 
within each group into batches and attach a batch code for that polling place. 
Paper bal ots are also put into batches with unique identifiers for scanning.  Electronic votes from 
scanning are uploaded to the counting module of eVACS® with identifiers based on the batch 
identifiers.   
Telephone voting system 
The telephone voting system comprising two operations:  
i) 
registering to vote by telephone, and  
ii) 
voting via telephone. 
The registration process is a manual process in which electors cal  an EACT service and provide 
information to establish their identity and that they are on the electoral rol , a private Personal 
Identification Number (PIN) to be used later when voting, and an email address which is used to send 
a unique voting token to the elector.  The PIN / voting token pair are used by the elector to 
authenticate themselves as a registered telephone voter.  The PIN / voting token pairs are stored in 
the telephone voting server to support the authentication process. 
4.3.4 Capabilities/functions of upgraded eVACS® 
4.3.4.1 Integrity of the software and the ballot data 
•  Software components are loaded into the various client and server hardware components.  
The integrity of such software components shall be maintained: once configured by officials 
for a particular election, it shall not be possible to make modifications to, or otherwise tamper 
with the software. 
•  The system shal  not allow ballots to be added, modified or deleted, other than by 
authenticated voters using the electronic voting client or telephone voting and DEOs using the 
paper bal ot entry interface. 
•  The electronic voting system shall have a form of checking to verify that the voter intention as 
expressed by their interaction with the client software is consistent with the vote recorded. 
4.3.4.2 Election setup 
EACT officials provide the following election information to eVACS®: 
1.  name and date of the election 
2.  names of the electorates 
3.  details of pre-poll and polling places, including batch numbers for paper bal ots 
4.  details of barcodes (e.g. pol ing place and electorate codes) 
5.  details of voting tokens for telephone voting (e.g. electorate codes) 
6.  information about rotation of candidates on the bal ot 
7.  date daylight saving commences in the ACT 
8.  the form of the bal ot papers 
9.  audio for vision-impaired voters 
10. names of the parties 
11. names of the candidates, identified by party (if any) or independent and electorate 
 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 20 
Setup procedures take place in two phases: 
Phase 1 Election information items 1, 2, 3, 4, 5, 6 and 7 are uploaded to eVACS®.  Electorate and 
polling-place-specific barcodes, including Master Admin barcodes, are generated and exported 
for sending to a contractor for printing in 2D format.  Voting tokens are generated and stored 
ready for incorporation into the telephone voting server instal ation software, and exported to 
enable assignment to registered telephone voters. 
Phase 2 Election information items 8, 9, 10 and 11 are uploaded to eVACS®.  The installation of 
voting servers can then be undertaken, including the installation for the telephone voting server. 
4.3.4.3 Electronic voting 
The fol owing functional requirements are carried over from those placed on the existing eVACS®: 
•  The system shal  ensure that each elector may vote at most once for the electorate in which 
they are enrol ed. 
•  The system shal  ensure that the bal ot paper appears to the voter without bias to a particular 
candidate or party. 
•  The bal ot paper should be easily readable. 
•  The system shal  protect the anonymity of each elector. 
•  The system shal  ensure that the system is capable of providing at the end of each day of the 
pre-polling period and pol ing day, electronic back-up copies (master and slave) of cumulative 
voting data held on the pol ing place server at each electronic pre-polling and polling centre. 
•  The system shal  allow for voting data to be transferred to the vote counting system without 
being accidentally or deliberately lost, altered, copied or stolen. 
•  The data transfer should occur in a timely manner that ensures that the vote counting system 
is able to complete preference distribution of all votes cast electronical y as soon as 
practicable on polling night. 
•  The system shal  be secure and once the code is verified and audits are complete code 
should be certified and locked so no further changes can be made. 
There are 4 key screens displayed on the voting client during the electronic voting process: 
i) 
Welcome screen linked to selecting language and having barcode read 
ii) 
Main (voting screen) where voters select their candidate choices in order of preference 
iii) 
Confirmation screen - where voters review their choices and either Confirm (with a second 
reading of their barcode) or return to change their choices 
iv) 
Thank you for voting (Acknowledgement or Acceptance) screen – advising that the voter’s 
vote has been accepted 
Other screens are used to display error messages, for informal voting, or if the voter wants to hide 
their vote while they seek assistance from an official. 
Instead of navigating with a keypad to move between and around screens and to select candidates, 
with a touch screen voters wil  be able to touch a candidate’s name/preference box and use screen 
buttons, such as ‘Clear Choices’, ‘Undo Last Choice, for changing candidate selections, and ‘Next’, 
‘Go Back’ to move between screens.  The names of buttons are to be agreed with the EACT. 
The setup for B&VI voters remains unchanged. 
4.3.4.4 Data entry or scanning of paper bal ots 
For those electors who vote using a paper bal ot the voting procedure and the collection of bal ot 
papers remains unchanged.  Similarly, the processes for obtaining electronic vote data from either 
data entry or scanning of paper ballots are unchanged. 
 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 21 
4.3.4.5 Counting and reporting 
The vote counting program produces the required scrutiny sheets for the election.  The program 
calculates preference distribution results using the data stored in the ‘committed’ votes database, 
which contains electronic votes (from polling places and telephone voting server) and votes from 
scanning and/or manual entry of preferences from paper ballots.  Progressive reporting, from election 
night onwards, is possible during the process of scanning or entering paper bal ots. 
The counting system can export its own vote data and import vote data generated by any electronic 
voting server.  Each bal ot stored in the votes database is tagged in such a way as to prevent it from 
being counted twice. 
The counting system can also be operated when a casual vacancy arises and a countback is required. 
The fol owing functional requirements are carried over from those placed on the existing eVACS®: 
•  The system shal  provide an audit trail for election results. 
•  The system shal  be capable of being tested by election officials under load conditions to the 
satisfaction of election participants prior to acceptance of the system. 
4.3.5 Performance characteristics 
The fol owing characteristics are carried over from those placed on the existing eVACS®: 
•  After the electronic voting client is used to cast a vote, the voting client shall be ready for the 
next elector within a specified time. 
•  After the paper bal ot entry client is used to enter a paper ballot, the ballot entry client shal  be 
ready to enter a new ballot within a specified time. 
4.3.6 Quality attributes 
The system shal  allow programming code to be independently audited and be available to scrutineers 
for verification and to ensure “what goes in is what comes out”. 
Auditing of software is not a simple task and while eVACS® has passed all audits to date not every 
aspect of the software has been thoroughly examined.  From Barnes (2015) “Ada introduces 
restrictions and checks, with the goal of providing freedom from errors.  On the other hand ‘C’ gives 
the programmer more freedom, making it easier to make errors“, which provides an argument to 
support migrating eVACS® from ‘C’ to Ada. 
In addition, the Ada programming language has been a standard since 1983 (original y an ANSI 
standard), with the latest version of the Ada language issued as an ISO standard in December 2012 
(known as Ada 2012). 
After Barnes (2015) the recognised features of Ada that when used lead to quality programming 
include: 
•  Clear and unambiguous syntax 
•  Strong typing 
•  Limits the use of pointers 
•  Architecture that groups related entities together 
•  Object-oriented programming that encapsulates types 
•  Object construction controls 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 22 
•  Memory management 
•  Correct startup 
•  Safe and secure communication 
•  Concurrency within the language 
•  Certified with SPARK 
Barnes (2015) describes Ada as “an excellent language for writing reliable software. Ada al ows 
programmers to catch errors early in the development process.  Even more errors can be detected by 
using SPARK without having to rely on testing – a difficult and error-prone process in itself, yet an 
indispensable part of the software process. 
For the highest level of security-critical applications it is not enough for a program to be correct. It also 
has to be shown to be correct.  This is usual y cal ed certification and is performed according to the 
methods of a relevant certification agency.  SPARK is of great value in developing programs to be 
certified as safe or secure as appropriate. “ 
4.3.7 Provisions for security and recovery 
The fol owing characteristics are carried over from those placed on the existing eVACS®. 
•  The system shal  ensure that two backup copies of the electronic voting data are recorded in 
separate locations within the pol ing place immediately after a vote is cast and confirmed by 
the voter. 
•  The system shal  ensure that the system is capable of providing at the end of each day of the 
pre-polling period, electronic back-up copies of voting data from each pre-polling centre. 
•  The system shal  provide for the transfer of electronic voting information (not via the Internet or 
any publicly accessible network) from voting at pre-poll centres and pol ing places at the end 
of pol ing on pol ing day to the computer vote counting system. 
•  The system should be capable of operating securely in order to ensure data is not accidentally 
or deliberately lost, altered, copied or stolen. 
•  The system shal  support backup of the election setup and data entry servers. 
As John Barnes (2015) stated “The world is becoming more and more concerned about both safety 
and security.  Accordingly, it is important that software for systems in which safety or security are a 
major requirement should be safe and secure.”  In 2019 security in government systems is of major 
importance, with governments in Australia requiring penetration testing and IRAPS to demonstrate the 
security of existing and new systems.  
As a consequence, the security features within eVACS® are to further strengthened as in section 4.1. 
4.4  User/affected personnel 
The fol owing categories of user are involved in the operation of eVACS®: 
•  Election officials 
•  Hardware and technical support 
•  Polling place officials 
•  Voters 
•  Data entry operators, if data entry of paper ballots is required 
Although scanning operators are involved in scanning paper bal ots, they have no involvement with 
eVACS®. 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 23 
4.5  Support and maintenance 
Support for EACT is negotiated on an as required basis. 
With a four-year Legislative Assembly election cycle, eVACS® is only used every 4 years for an 
election, although recounts for Casual Vacancies may occur in the intervening period.  EACT has 
included in the upgrade contract maintenance of the system in the year preceding the next election to 
ensure the latest versions of software are incorporated in preparation for the election. 
 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 24 
5.  Operational scenarios 
Sample interactions with various components of the upgraded eVACS® are provided at a high level 
for electronic voting, including touch screen voting, keypad with audio voting and telephone voting, 
and data entry of paper ballots.  The examples are not intended to capture al  possible interactions 
within each component, but rather as an aid to understanding the broad scope of the system. 
Detailed event-action lists are included in the Software System Specification. 
5.1  Electronic voting 
The fol owing scenarios il ustrates successful electronic voting by a voter.  Treatment of error 
conditions (e.g. unsuccess read of barcode) or informal voting is omitted.  There are three scenarios: 
•  Touch screen voting 
•  Keypad with audio voting 
•  Telephone voting 
5.1.1 Touch screen voting  
1.  Voter has name marked off on electoral roll, receives e-voting card from pol ing official, and 
proceeds to electronic pol ing booth. 
2.  Voter sees Welcome message with option to select language and then instruction in selected 
language to scan e-voting card to start voting. 
3.  Voter places e-voting card under barcode reader.  If valid e-voting card, the Main Voting 
screen is displayed, with the entire ballot paper viewable on screen. 
4.  Voter presses screen for desired first preference candidate.  Preference box against 
Candidate name is highlighted and the number 1 appears in the box. 
5.  Voter then presses another candidate name for second preference and so on, with the 
number 2, etc appearing in the box next to the candidates in order chosen. 
6.  Voter presses NEXT button. The vote confirmation screen is displayed, which lists the names 
and parties (if any) of the previously selected candidates in increasing order of preference. 
7.  Voter has option to GO BACK to Main Voting screen or to scan e-voting card to cast vote. 
8.  Voter places e-voting card under barcode reader.  If the two barcode reads match, the vote is 
accepted and the vote acceptance screen is displayed. 
9.  After a timeout, the Welcome screen reappears. 
5.1.2 Keypad with audio voting  
1.  Voter has name marked off on electoral roll, receives e-voting card (and headphones if 
required) from pol ing official, and proceeds to electronic pol ing booth. 
2.  Voter puts on headphones (and if necessary seeks assistance to plug in headphones) and 
hears welcome message and instructions to press any key to find out what it does played in a 
loop, with message to scan e-voting card to commence voting. 
3.  Voter places e-voting card under barcode reader and If valid barcode the group heading 
where the cursor is randomly located is announced.  
4.  Voter navigates between groups by selecting the 4 (previous) or 6 (next) key, and up/down to 
candidates within a group by selecting the 2 (up) or 8(down) key. 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 25 
5.  When voter reaches first choice of candidate, audio announces the name of candidate and 
group, and when voter presses the SELECT (5) key, the name of candidate, group and the 
preference number, in this case ‘one’, are announced. 
6.  Voter navigates up/down between candidates and previous/next between groups and for each 
press of the Select key until they have selected all their preferences, numbered in increasing 
sequential order. 
7.  When al  choices have been selected, the Voter presses the FINISH (#) key.  The names of 
candidates and their groups and preference numbers are then announced in order 
commencing with their first preference. 
8.  If selection list is correct, the Voter places their e-voting card under the reader again.  If the 
two barcode reads match, the vote is accepted. 
9.  Voter receives a message to say their vote has been accepted and thanking them for voting. 
10. After a timeout, the welcome message is heard. 
5.1.3 Telephone voting  
1. Voter has previously registered for telephone voting, provided a private Personal Identification 
Number (PIN) and received an email with a unique voting token. 
2.  Voter cal s the telephone voting number and selects 3 to vote (selecting 1 is registering to 
vote, selecting 2 to hear voting instructions). 
3.  Voter hears message welcoming them to the ACT Legislative Assembly election, and they are 
asked to enter their PIN fol owed by their voting token. 
4.  If PIN and voting token pair match with a pair in the database, audio is played with instructions 
on how to vote by using the telephone keypad and when they are ready to vote to press 3 (a 
currently unused key in the B&VI system).   
5.  Voter presses 3 and audio is played announcing the electorate of the ballot paper and at 
which group the system is currently located.  
6.  Voter navigates between groups by selecting the 4 (previous) or 6 (next) key, and up/down to 
candidates within a group by selecting the 2 (up) or 8 (down) key. 
7.  When voter reaches first choice of candidate, audio announces the name of candidate and 
group, and when voter presses the SELECT (5) key, the name of candidate, group and the 
preference number, in this case ‘one’, are announced. 
8.  Voter navigates up/down between candidates and previous/next between groups and for each 
press of the Select (5) key until they have selected all their preferences, numbered in 
increasing sequential order. 
9.  When al  choices have been selected, the Voter presses the FINISH (#) key.  The names of 
candidates and their groups and preference number are then announced in order 
commencing with their first preference. 
10. If selection list is correct, the Voter enters their PIN again.  If the PIN is a match with that 
entered at the start of the voting session, the vote is accepted. 
11. Voter receives a message to say their vote has been accepted and thanking them for voting. 
12. The system then terminates the telephone connection. 
5.2  Paper bal ot entry 
The fol owing scenario il ustrates successful entry of a batch of bal ot papers.  The treatment of error 
conditions (e.g. entering an invalid batch number) is omitted. 
1.  DEO enters the batch number of the ballots. The batch number is accepted. 
2.  DEO enters rotation number of the first ballot paper in the batch. The rotation number is 
accepted, and the electronic version of the bal ot paper is displayed. 
3.  DEO enters the preferences selected on the first bal ot paper. 
4.  DEO presses the END PAPER key. The ballot confirmation screen is displayed. 
5.  DEO presses the ENTER key. The ballot is accepted. 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 26 
6.  DEO enters remaining bal ot papers of the batch in the same way. 
7.  DEO presses the END BATCH key. The batch confirmation screen is displayed. 
8.  DEO presses the ENTER key. The batch is accepted. 
 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 27 
Annex A: Format of file for upload to LAPPERDS 
The file format for the csv file output, to be uploaded to LAPPERDS, is defined by the EACT as 
follows. 
   •  Format: CSV (comma separated values) 
•  Header row required (but column names not important) 
•  Name: FirstPreferences*.csv  (the * part is optional and can be anything) 
•  Columns: 
  Position  Column heading  Mandatory?  Value/relation 

PollingPlaceID 
mandatory 
qryELAPPSPol ingPlaces-withpasswords.csv column 


ElectorateID 
mandatory 
qryELAPPSElectorates.csv column 1 

CandidateFirstName  mandatory 
qryELAPPSCandidates.csv column 1 

CandidateLastName  mandatory 
qryELAPPSCandidates.csv column 2 

PaperCount 
optional 
Paper first preference 

ElectronicCount 
optional 
Electronic first preference 
 
Clarifications 
•  It is a single file, but it can be uploaded multiple times. 
•  Two of the columns (Paper Count and Electronic Count) are optional, and if omitted wil  be 
considered zero. However, as with all CSV uploads, when a column value is omitted, the 
column must stil  be denoted with a comma. 
•  The required format for informal votes is to use the word “Informal” in place of both 
‘CandidateFirstName’ and ‘CandidateLastName’ fields. 
•  The CSV file is just plain text. 
  
Example content for a test file: 
  
PollingPlaceID,ElectorateID,CandidateFirstName,CandidateLastName,PaperCount,ElectronicCount 
103,2,Chris,Bourke,167,73 
80,2,Yvette,Berry,320, 
66,4,Informal,Informal,71, 
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 


 
 
Operational Concept Description 
 
 
Page 28 
Annex B: Glossary  
Abbreviation or Term 
Meaning 
ACT 
Australian Capital Territory 
ACTEC 
ACT Electoral Commission (also EACT) 
ACTGS 
ACT Government Solicitor 
Ada 
Ada is a structured, statical y typed, imperative, and object-oriented 
high-level computer programming language 
ANSI 
American National Standards Institute 
AIAA 
American Institute of Aeronautics and Astronautics 
ASD 
Australian Signals Directorate 
B&VI 
Blind and Vision Impaired 
CJB 
Carol Boughton 
CVB 
Clive Boughton 
DEC 
Deputy Electoral Commissioner 
DEO 
Data Entry Operator 
EACT 
Elections ACT 
eVACS® / eVACS 
electronic Voting and Counting System 
IRS 
Interface Requirements Specification  
MD5 
Message Digest algorithm 5 
ICT 
Information and Communications Technology 
IT 
Information Technology 
LAN 
Local Area Network 
OCD 
Operational Concept Description 
Polling place 
Includes pre-pol  centre and locations where voting occurs on Election 
day and at which electronic voting is to be provided 
Pre-poll centre 
A location in the ACT where voting is permissible prior to election day 
and at which electronic voting is to be provided 
QR code 
A form of 2-dimensional barcode (2D barcode) 
RB 
Russell Baird 
SHA-2 
Secure Hash Algorithm 2, a set of cryptographic hash functions 
SIPL 
Software Improvements Pty Ltd 
SPARK 
A formally defined computer language based on the Ada language, 
intended for the development of high integrity software used in 
systems where predictable and highly reliable operation is essential.  
Is especial y used in safety critical systems. 
WORM 
Write Once Read Many 
–   E N D   O F   D O C U M E N T   –  
Commercial-in-Confidence 
 
Software Improvements Pty Ltd © 2019 

Document Outline