ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010

STANDARD SPECIFICATIONS FOR THE SUPPLY OF ELECTRONIC ACCESS CONTROL SYSTEM AND RELATED COMPONENTRY AND SOFTWARE TO THE AUSTRALIAN NATIONAL UNIVERSITY AS ISSUED BY ANU SECURITY 29 MARCH 2010

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010

STATEMENT OF REQUIREMENT
1. BACKGROUND TO THE REQUIREMENT

The University existing system is a Cardax access control system. During 2010 it will operate using Smartswipe mag stripe readers. Schneider Electric Buildings Australia PL and Cardax are contracted to changeover the readers to Mifare Plus (128 bit AES encryption) in 1st Quarter 2011 as part of the campus wide project proceeding during 2010. Project Managers should allow for the changeover cost during the period nominated for the two types of readers in addition to the new installation cost. Note 1: that this University specification requires compliance with Australian standards AS14443-2003 parts 1 to 4 on this component with important additional requirements. Note 2: The access control system will also need to comply with any project tender specifications issued by the University, relevant Australian Standards and codes as applicable. University documents supporting this specification and requiring tender compliance include the ANU General Electrical specification and the ANU Structured Cable specification. The documents are available to consultants and contractors via the Web. Note 3: Commissioning acceptance in any project by ANU Security of any access control system work on behalf of the University will be in accordance with this document and be informed by the pre commissioning information supplied by the Project Coordinator and Project Manager. Project Managers are also advised to ascertain from University clients the level of interfacing between the Cardax system and other security and building systems at the time of project design.

2. 2.1 2.1.1

REQUIREMENT REPLACEMENT OF MAG STRIPE CARD TECHNOLOGY CARDS AND 125 KHZ READERS (STAGE 1). The ANU uses a mixture of mag stripe and Cardax 125 readers and cards. To allow for the migration the replacement card to be supplied must be able to work as a minimum with Cardax or equivalent high coercivity mag stripe specification readers and Proximity readers as well as be able to be encoded by both types of encoders to the Cardax specification or equivalent. In 2011 the card used will be a dual tech mag stripe and Mifare Plus proximity card. The card specifications will need to comply with Australian Standards AS14443-2003 parts 1 to 4 for proximity cards used with the Cardax or equivalent System. The University has specified a minimum requirement of 128 bit AES encryption for the proximity card system chosen Cardax Mifare Plus reads from 1st Qtr 2011. REPLACEMENT OF EXISTING HARDWARE WHERE REQUIRED 2

2.1.2

2.1.3

2.2

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 2.2.1 This work is to be carried out in accordance with ANU specifications for access control and appropriate university electrical and site works specifications. Tenderers will need to consider University advice on our calendar of events and the schedule of works when submitting a project schedule and how the tendered work would be accomplished with minimum or no impact on the functions of the University. Clear descriptions of how the work would be accomplished within buildings are required from the tenderer in their submission to allow assessment of the tendered project schedule. Areas of possible concern for the tenderer need to also be clearly explained in the compliance statements. INSTALLATION OF ACCESS SYSTEM ON PRESENTLY MANUALLY SECURED DOORS ON CAMPUS BUILDINGS THROUGHOUT ACTON CAMPUS. The University has a number of buildings that are fully or partially locked manually each day. The University is looking for tenderers to provide component project pricing so that the University may decide the effectiveness of pursuing all or part of this stage with a successful tenderer. The University will also be using stage 3 component pricing submitted in the tender to calculate any installation of access control or hotel keying on doors it may decide are required to have access control in addition to the requirements identified in the RFT material schedules for existing installations as attached. SCOPE OF THE REQUIREMENT The University requires the tenderer to provide full and detailed costs for the delivery and completion of this project. The tenderers response will need to provide sufficient information and detail to allow full assessment of the submitted tender. Tenderers shall confirm the cards, readers and all system equipment related to the system operation to be supplied under a contract arrangement are fully compliant with relevant Australian and International standards, particularly but not exclusively AS14443 parts 1-4 (2003). The University during 2010 operates Datacard printers (model SP75) with Magnetic stripe encoders and or Proximity encoders included. Tenderers shall confirm the system components tendered for the access control system are capable of interfacing at the software and physical levels with the printers and card hardware system in use at the University or to provide systems of equivalent capability The University reserves the right to source its computing equipment, printers and card encoders directly and separately to any needs described by this specification.

2.2.2

2.2.3

2.3 2.3.1

2.3.2

3. 3.1.1 3.1.2 3.1.3

3.1.4

3.1.5

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.2 3.2.1 NEW ACCESS CONTROL INSTALLATION TO DOORS ON CAMPUS Tenderers shall provide a pricing structure to carry out the installations indicated on the drawings in compliance with the requirements of the tender. The clear pricing tendered shall allow the University to identify the cost on a per door basis. FUNCTIONAL OVERVIEW OF THE SYSTEM REQUIREMENTS 3.3 3.3.1 FUNCTIONAL OVERVIEW ELECTRONIC ACCESS CONTROL SYSTEM CAMPUS
WIDE SYSTEM

3.2.2

The system shall provide a means to control access through nominated doors having electric locking door status monitoring and access control readers. Access rights associated with a presented access token shall be checked for validity based on token, access area, access time and any other access management function defined in this specification; as stored in intelligent field controllers. Access shall be granted or denied, dependant on the access privilege. Access rights shall be programmed in a variety of ways to allow flexibility as defined elsewhere in this specification. The system shall provide access control in elevators as identified in schedules enabling the access of each cardholder to have access to any combination of floors over specified time periods. The interface to the elevator manufacturers equipment shall be by either low level interface (relay outputs) or preferably by a high level (data) interface. The system shall monitor the condition of inputs. The system shall be able to be programmed to apply a variety of conditions to the way in which these inputs are monitored and shall enunciate the condition of such inputs in accordance with such programming. The system shall provide a fully functional intruder alarm system including entry and exit delays where intruder detection sensors are connected to system inputs. The Intruder Alarm Systems component shall be fully integrated with the Access Control aspects of the system. It shall be possible to set (secure) or unset (unsecure) areas from any access control reader associated with an area, or via Remote Arming Terminals or as required from defined central control locations. Intercom functionality shall be integrated with a card reader, enabling a card reader user to talk to an operator as and when required, and an operator to talk directly to the card reader user. All intercom communications shall utilise the common Integrated Security system network and communications cabling infrastructure; and be fully integrated with the access control system. The system shall provide an integrated software facility for the design and production of photo ID cards.

3.3.2

3.3.3

3.3.4

3.3.5

3.3.6

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.3.7 The system shall be OPC Alarms and Events enabled using Microsoft COM and DCOM enabling integration of event data with other third party OPC enabled automation and business systems. The system shall allow data exchange with other applications using XML protocols for schedule changes, and card record changes. The system shall be capable of carrying out the data exchange on a batch or real time processing basis. The current operating system used by the system server Microsoft Windows 2003. If SQL Server 2005 is used, the system server shall be Microsoft Windows 2005 Server (enterprise edition). Client terminal software shall be Microsoft Windows XP Professional compatible. If an alternative operating system is offered, full details must be supplied on how the alternative meets the criteria laid out in the RFT. All system communications must be totally integrated with either existing or new firewalled LAN/WAN networks using the ANU IP numbering scheme. Tenderers must make themselves familiar with the specific requirements for this project. Connection to Intelligent Field Controllers (IFCs) shall be achieved using Ethernet cabling supporting 10baseT and TCP/IP protocols. The network connection must be on-board the IFC. Interface transceiver units (10BaseT to RS485, RS232 etc) are not acceptable. Remote IFCs not permanently connected to the network can be connected via a PSTN service, using TCP/IP protocols. Connection from the remote IFC to the server shall be either via dialup to an Internet Service Provider (ISP) using encrypted TCP/IP; and then via an approved firewall through into the IT environment or via dialup directly to a RAS connection to the Server All system software upgrades shall be downloadable through the network to the IFC. All data communication internal to the system on the TCP/IP network between IFCs and between IFCs and the Server shall be encrypted using symmetrical session keys and an industry-standard encryption algorithm to a minimum of 40 Bits (Secure Socket Layer). Session keys shall be changed on a regular basis at intervals no longer than 24 hours. The system shall report all events to the operator(s) as configured and shall produce and maintain a log of all system events, alarms and operator actions. The system shall provide a means for an operator to extract information relative to the event log and system configuration and produce this information in the form of printed reports, screen displays or ASCII files. The system shall provide for a Windows based User Interface with Site Plans and interactive icons representing the location and real-time status of Access Control, and Alarm Monitoring equipment. The system must provide emergency evacuation reporting.

3.3.8

3.3.9

3.3.10

3.3.11

3.3.12 3.3.13

3.3.14 3.3.15

3.3.16

3.3.17

3.3.18

3.3.19

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.3.20 3.3.21 The system shall be designed and manufactured by a reputable company who shall be certified under the ISO 9001:2000 quality procedures. All equipment shall have the following approvals: (a) (b) (c) 3.3.22 (a) (b) (c) 3.3.23 FCC Part 15 CE approval BS EN 50130-4 Alarm Systems Electromagnetic Compatibility (Immunity) CE approval BS EN 55022 Emissions CE ETS 300 683 Short Range Devices C-Tick AS/NZS 4251 Generic Emission Standard C-Tick RFS29

Encoders and readers shall also meet:

The system software shall be written in a fully structured, fully validated and commercially available language that provides a strictly controlled development environment. Comprehensive backup and archiving facilities shall be incorporated as an integral part of the system software. The system shall include system division suitable for multi-tenanted buildings. Operators shall only be able to access those parts of the system which fall within their division and operator privileges. IFCs must support peer to peer communications for input and output communications between IFCs. Systems that require the main server for communications between panels are unacceptable. SYSTEM REQUIREMENTS The system described in this specification must have the following capacity as a minimum: (a) (b) (c) (d) (e) (f) (g) (h) (i) (j) (k) (l) Graphical Site Plans Access Readers 4000 Readers with intercoms 500 Elevators 100 elevators each with up to 75 levels Fully Supervised 4 state Alarm Inputs 30,000 Output relays 20,000 4000 100 50 Access Control Zones Schedules per day Schedule categories Holiday days Operators 500 Concurrent Operator Sessions 20 minimum 100,000 preferably 1,000,000 6 30 2000

3.3.24 3.3.25

3.3.26

3.4 3.4.1

(m) Cardholders

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 (n) (o) 3.4.2 (a) (b) (c) 3.5 3.5.1 3.5.2 Cardholder Issue Levels 15 Cardholder Personal Data Fields 64

The system architecture shall be a tiered system consisting of: Head-end software application operating on a computer server; Intelligent Field Controllers (IFCs) managing the system in a distributed intelligence format; Semi-intelligent subunits (outputs, inputs, readers, etc) which rely on IFCs to function.

CENTRAL CONTROL AND SYSTEM MANAGEMENT SOFTWARE The system shall use the Microsoft Windows operating system. The version of Microsoft Windows shall be a currently supported version. The system database shall be a version of Microsoft SQL Server Enterprise edition. The version of Microsoft SQL Server shall be a currently supported version. The University will arrange a license for the software directly through their University licensing system. The system shall be OPC enabled in accordance with the current OPC specification for OPC alarms and events to operate as an OPC server The tenderer will identify in detail the specification required for a server computer suitable for a system of the size to be used by the University. Due consideration in the site assessment must be given to site activity, database size and manipulation of it, number of operators on the system at any time, changes being made to the database when migrating from the existing system so as to ensure a specification that performs routine functions and activities without noticeable lag or delay for operators. The University reserves the right to purchase, supply and install the recommended server and client software to the specifications provided by the tenderer in the submission. The system shall be supplied (and licensed if required) with a minimum of 20 operator workstations simultaneously running. Operator workstations running terminal emulation software will not be accepted. The system shall support secure web based thin-client architecture to provide operator access to at least the following functions: (a) (b) (c) Cardholder management Event and alarm management The opening and closing of doors defined in an operators work zone or access group

3.5.3 3.5.4 3.5.5

3.5.6

3.5.7

3.5.8

3.6 3.6.1

OPERATOR FUNCTIONALITY The web based operator access shall support operator functionality as detailed below:

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 (a) (b) The web access shall be managed via a web server to provide firewall isolation from the main server. The system shall automatically log and time/date-stamp all events within the system including intruder alarm set/unset events, access control events, operator actions and activity. The central control software shall be demonstrably easy to use, make extensive use of menus and windows and require a minimum of operator training to operate the system proficiently. Systems requiring a program language approach to configure the system will not be accepted. The central control must be capable of receiving simultaneous alarm signals from a number of remote locations, without loss or excessive delay in their presentation to the operator. Any authorised operator should be allowed to acknowledge, view and/or process an alarm from any screen. The central control shall be fitted with a real time clock, the accuracy of which shall be preserved over the period of main power supply failure. Synchronisation between the central control and Ethernet connected IFCs shall be automatic, not requiring operator intervention. Operator selection of processing tasks shall be via menu selections. Authorised Operators shall be able to process alarms, produce reports and modify database records without degrading system performance.

(c)

(d)

(e)

(f)

3.7 3.7.1

OPERATIONAL AND MONITORING FACILITIES The following is the minimum operational and monitoring facilities required. The ability to: (a) (b) (c) (d) (e) Program either a group or individual card readers with access control parameters, without affecting other card readers. Program the access criteria for individual Cardholders or groups of Cardholders. Store at least 64 non-access control data fields for each cardholder. The names of these Personal Data fields shall be user definable. Authorise or de-authorise a Cardholder in the system with the result reflected immediately throughout all readers in the system. Enable a Card Trace against selected Cardholders so that an alarm is raised each and every time that cardholder presents their access card or token. Pre-program holidays so that different access criteria apply compared to normal working days. The system must have a capacity to set at least 30 holiday days. Recognise and manage regional holiday requirements Define as many access zones as there are card readers fitted. 8

(f)

(g) (h)

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 (i) (j) (k) (l) 3.7.2 3.8 3.8.1 Allow or disallow individual Cardholder access to any one, or group of card readers, in real time. Log all system and operator activity to hard disk as they occur. Program alarm response instructions into the system so that these are presented to the Operator when processing an alarm event. Enable an Operator to enter messages against alarm events.

Override (temporarily) a Cardholders, or group of Cardholders, preprogrammed access criteria. CENTRAL CONTROL The central control shall display a one-line plain language event message for every activity event (alarm or otherwise) occurring in the system. All activity logged shall be time and date stamped to the nearest second (hh:mm:ss). On having the appropriate operator authorisation it shall be possible to drill down into the properties of each component that makes up that event for future details. The event message shall advise: (a) (b) (c) (d) Time of event Action Successful or unsuccessful If the transaction is unsuccessful, the reasons for the denial. This includes but is not restricted to the following items: (i) (ii) (iii) All card attempts All door alarms All operator activity including log on, log off, alarm response messages and any alteration of system data files All communications link failures.

(iv) All alarm monitoring activations (v) 3.8.2 3.8.3 3.8.4 3.9 3.9.1 Time schedules for different day types shall be configurable. Regional holidays shall be configurable to allow for regional variations. Access group expiry dates shall be able to be created for different dates to the card expiry dates SITE PLANS AND SITE PLAN ICONS It shall be possible to manage and monitor alarms, overrides, the general status of site items and open doors through the Graphical User Interface with the use of interactive real time dynamic site plans and icons. A minimum of 2,000 graphical site plans must be available. All site plans stored on the Server shall be automatically updated if amended at any of the networked workstations. External drawings shall be imported into the system from external drawing software.

3.9.2

3.9.3

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.9.4 The ability to import at least the following drawing formats shall be supported: (a) (b) (c) (d) 3.9.5 3.9.6 3.9.7 BMP WMF JPEG GIF

It shall be possible to assign icons to system functions and place these at any position on a site plan. Site plans shall be nested allowing a single action (mouse click on a current site plan icon) to move from one site plan to another. The following functions should, as a minimum, be able to be executed by clicking on Site Plan icons: (a) (b) (c) (d) (e) (f) (g) View the current status of a Door, Input or Output. Monitor and acknowledge an Alarm Open an access controlled door Move from one plan to another plan Activate an Intercom on a reader Override an alarm, access or perimeter fence zone state. Display the properties of the item.

3.9.8 3.9.9 3.9.10 3.9.11 3.9.12

Icon names shall use the item name by default but a short name shall be selectable if available. The size of the Icons shall be scalable. A pre-designed set of icons covering basic access control functions shall be provided. It shall be possible to design and load icons from external software for use in the system. It shall be possible to design macro buttons to reside on site plans. On activation, macro buttons must be capable of performing multiple overrides for any site items simultaneously. Macro buttons or icons must display the current state of system activation for the function it is linked to, until a change of state (operator or time reactivation) occurs. FIELD HARDWARE The IFC shall be the main controller in the field. The head-end application shall communicate directly with all IFCs in the system. Each IFC shall be intelligent in that in the event of failure of power or communications to the central control, for whatever reason, the system shall continue to allow or deny access based on full security criteria. The IFC shall store on-board all the security and access parameters to operate completely independently from the central control server. 10

3.9.13

3.10 3.10.1 3.10.2

3.10.3

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 Systems that rely on the central control PC for access decisions will not be considered. 3.10.4 3.10.5 3.10.6 3.10.7 3.10.8 3.10.9 The IFC shall "concentrate" activity data and immediately transmit it to the central control server computer. In its standard configuration, each IFC shall be capable of buffering 10,000 events should communications fail with the central control. All events shall be time-stamped at the IFC at the time of occurrence. The IFC shall recommence transfer of buffered events to the central control automatically when the communications link is re-established. The IFC shall be capable of storing at least 30,000 cardholder records with associated access criteria in its standard configuration. The ratio between stored events and stored cardholders shall be configurable for each IFC to allow site requirements to be configured in accordance with specific site needs (more cardholders or more events per IFC). The system shall monitor input circuits and enunciate whether the circuit is in Normal, Alarm, Open Circuit Tampered or Short Circuit Tampered as separate conditions. A configurable range of end of line resistor values shall be supported as a software function to support pre-existing input circuits when required. The use of any circuits using other than dual 4k7 end of line resistors must be approved by the University project management team. The IFC shall include tamper protection for the front and the back of the panel. The front panel shall be tamper protected for door open, and the rear of the panel to detect if the panel has been removed from the wall. These shall use optical tamper detection. Mechanical tamper devices are not acceptable. The IFC shall incorporate a 32-bit processor with at least 4 Megabytes of non-volatile FLASH EEPROM. The IFC shall incorporate boot code in a protected sector of the flash memory. For software upgrades, all system software shall be downloaded from the central server over the network The IFC shall operate from a separate battery backed 13.6V DC supply. The IFC shall continue to operate for at least 8 hours in the event of a mains supply failure. The system shall be capable of automatically detecting and reporting a power failure, low battery and battery not connected. IFCs shall automatically restart and resume processing following a power failure. IFCs shall be fitted with "watchdog" hardware and software to provide automatic detection and restart should the processor lock up. The IFC shall contain its own battery backed real time clock. The battery shall have a minimum life of ten years. The clock shall be synchronised with the central controls clock at least once per hour. The accuracy shall 11

3.10.10

3.10.11 3.10.12 3.10.13

3.10.14

3.10.15 3.10.16 3.10.17 3.10.18 3.10.19 3.10.20

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 be such that the time difference between IFCs shall not vary more than 0.5 second at any time. 3.10.21 3.10.22 3.10.23 3.10.24 The IFC shall be allocated to a time zone appropriate to the IFC location. The IFC shall have an on board 10BaseT Ethernet (TCP/IP) connection and driver for communications with the central control. Should excessive network broadcast traffic occur (resulting from a ping attack or similar), an alarm shall be generated. All communications between the IFC and the system PC shall be encrypted TCP/IP. Communications shall be on-line and monitored for interruption. The IFC shall include a least one other RS 232 multi-communications port. The IFC shall support remote site dial-up. Remote communication between the IFCs and the remote devices shall use the switched telephone network circuits. Incoming connection shall be allowable via an ISP service. Outgoing connections via modems connected to the customer LAN are not permitted, however dial-out directly from the Server is allowed provided the modem is fixed to non-answer mode. It shall be possible to view the IFC status and configuration for commissioning and diagnostic purposes without the use of the central server software or other proprietary software. This may be achieved by the use of conventional WEB based browser. In high security applications, it must be possible to disable this feature at the IFC. SEPARATE ALARM MESSAGE A separate alarm message, displayed in plain language text, shall be transmitted to the central control for at least the following alarm conditions: (a) (b) (c) (d) (e) (f) (g) (h) (i) (j) (k) (l) Tamper Tamper Return to Normal Unit Stopped Responding Card error Maintenance Warning Alarm Sector State Change User Set User Unset Card Trace Wrong PIN Access Denied Duress 12

3.10.25 3.10.26 3.10.27 3.10.28 3.10.29

3.10.30

3.11 3.11.1

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 (m) Zone Count Maximum (n) (o) (p) (q) (r) (s) (t) 3.11.2 Zone Count Minimum Door Open Too Long Forced Door Door not locked Power Failure System Reboot. Intercom

The IFC shall store and operate software modules assigned to it for the purposes of operating subservient hardware and site-associated functionality, including but not limited to: (a) (b) (c) (d) Door modules Elevator modules Alarm management Cardholder records Readers with intercoms Card access readers Card access readers with PIN keypads Elevator access equipment Alarm monitoring Input/Output panels and equipment Alarm response equipment

3.11.3

The IFCs shall communicate with and control the following equipment: (a) (b) (c) (d) (e) (f)

3.11.4

All communications between the IFCs and the remote devices shall be "on-line" at all times (a connection via a modem and line using dial-up shall be considered as being on-line). Any failure of a card reader unit and its communications with the IFC shall be raised immediately as a high priority alarm and shall not cause the IFC or other associated hardware to stop working correctly. The IFC shall communicate with remote devices (card readers, alarm equipment, elevator readers) using a fully encrypted data communications protocol. Unencrypted ASCII text or similar data transmissions are not acceptable. All communications between the IFCs and the remote devices must be check-digit coded to protect data from manipulation during transmission. All communications links between the IFCs and the remote devices shall be monitored such that an alarm is raised at the central control if the data being transmitted is corrupted or tampered with in any way. ACCESS CONTROL, SECURITY ALARM AND I/O PROGRAMMING

3.11.5

3.11.6

3.11.7 3.11.8

3.12

13

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.12.1 The system shall provide complete flexibility and be capable of programming an unlimited combination of access control, security alarm and I/O parameters subject only to performance and memory limitations within the IFC. For ease of programming Cardholders shall be grouped into access groups sharing the same access criteria. It shall be possible to assign an individual cardholder to an access group on a temporary basis with predetermined start and finish times. During the period of temporary access, the cardholder shall have the rights of the group to which they have been assigned in addition to any permanent access rights they may have been assigned. The access group property page shall display both permanent and temporary access members with the status of temporary members shown as: (a) (b) (c) 3.12.6 Pending (with the start and finish times) Active Expired

3.12.2 3.12.3 3.12.4

3.12.5

Any cardholder or access group in the system shall be able to be programmed to have access to any combination of controlled doors in the system with each period of access for each door controlled to within the nearest minute. The IFC shall check entry based on ALL of the following criteria: (a) (b) (c) (d) (e) (f) (g) Correct facility code Authorised card in database Correct issue number Authorised door / access zone Authorised time of day Correct PIN (If PIN entry is required) Double entry (anti-passback, anti-tailgating or escort modes).

3.12.7

3.12.8

Anti-passback mode shall be able to be configured in any of the following modes: (a) (b) (c) Disallow second access to an area if a valid exit has not previously been registered and generate an alarm (hard anti-passback). Allow second access to an area if a valid exit has not previously been registered but generate an alarm (soft anti-passback). Exclude specific Access Groups from the rules defined above. Automatically after a preset period after valid entry. Automatically at a standard time each day Manually as an over-ride. 14

3.12.9

Anti-passback rules shall be able to be reset by either: (a) (b) (c)

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.12.10 Must support Global Anti-passback allowing multiple access zones to be linked for the purpose of anti-passback, across multiple IFC devices utilising encrypted peer-to-peer communications. Anti-tailgate mode shall be able to be configured in any of the following modes: (a) (b) (c) 3.12.12 (a) (b) (c) 3.12.13 3.13 3.13.1 Disallow exit from an area if a valid access has not previously been registered and generate an alarm (hard anti-tailgate). Allow exit from an area if a valid access has not previously been registered but generate an alarm (soft anti-tailgate). Exclude specific Access Groups from the rules defined above. Automatically after a preset period after valid entry. Automatically at a standard time each day Manually as an over-ride.

3.12.11

Anti-tailgate rules shall be able to be reset by either:

Every incorrect PIN attempt shall be notified at the central control as an alarm condition. READERS Each reader shall be capable of automatically switching the access mode at a door at different times of the day, based on control parameters received from the central control. The following access criteria modes are required: (a) (b) (c) Free access Door is unlocked, no card entry required. Secure access Door is locked, a successful card attempt is required for valid entry. Door re-secures after access attempt. Secure + PIN access Door is locked, a successful card and correct PIN number attempt is required for valid entry. Door resecures after access attempt. Override from reader Members of certain access groups shall be able to change the access and PINs mode of the door at certain times. Dual Authorisation Access is granted when two different but legitimate cards are presented within a given time frame. Escort A second card is required to be presented from a cardholder who is nominated in the Escort Access Group. Shared PIN Number The system Operator determines what the PIN number will be and programs this into the system. Access is allowed through the door when the correct 4 digit PIN is pressed followed by the Enter key.

(d)

(e) (f) (g)

3.14 3.14.1

CARDHOLDER ACCESS Cardholder access reporting to the central control and logging in the audit trail shall be configurable in two modes: 15

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 (a) Only when there has been a successful presentation of a valid access card or token AND the door open sensor has detected that the door has actually been opened. Whenever there has been a successful presentation of a valid access card irrespective of if the door has been opened.

(b) 3.14.2 3.14.3

Readers with integrated PIN pads shall provide an Entry under Duress facility. Duress shall be initiated by the cardholder either by the addition of a unique number to their PIN number, or by incrementing the last digit of their PIN number by one. There must be NO indication of a Duress entry at the reader. A high priority Duress Alarm shall be displayed at the central operator station. Zone counting shall be available to provide real-time counting of cardholders in access zones. The result of the number of cardholders in the zone being outside of the specified range(s) shall generate an event or an alarm. The minimum and maximum numbers of cardholders in a zone before an event is generated shall be configurable. It shall be possible to set up a grace time in seconds to allow the zone count to be outside the minimum within the mid range or outside the maximum number of cardholders, without generating an event. It shall be possible to assign a specific message for each of the below minimum, mid range or above maximum conditions. It shall be possible to set up the system to prohibit one cardholder being allowed in a zone by: (a) (b) (c) (d) (e) Requiring two valid but different cards to access a zone should the zone count reports zero cardholders in the zone; Requiring one card to access a zone should the zone count report two or more cards in the zone; Requiring one card to exit from a zone should the zone count report three or more cards in the zone; Requiring two valid but different cards to exit from a zone should the zone count report two people present; Prohibiting exit from a zone and generate an alarm if the zone count reports one person present.

3.14.4 3.14.5 3.14.6 3.14.7 3.14.8 3.14.9

3.14.10 3.14.11

3.15 3.15.1

PRE-PROGRAMMED OVERRIDE FUNCTIONALITY (MACROS OR ALTERNATIVES) To allow for making changes to the system configuration on demand, it shall be possible to pre-configure the required changes and assign them to a macro command.

16

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.15.2 An operator shall be able to initiate the macro (to carry out the changes) via either a menu item or by a site plan icon. Note the earlier requirement re change of state indication on buttons or icons. The functionality either via a macro or pre programmed override functionality shall be able to be initiated on a time schedule. Alternative program functionality (in lieu of macros) is to be clearly described as to its operation and compliance with the specification. DOOR CONTROL Access control for a door shall allow for the following features where specified: (a) (b) (c) 3.16.2 Access reader Emergency release switch input Reception control switch input

3.15.3 3.15.4 3.16 3.16.1

Egress control for a door shall allow for the following features where specified: (a) (b) (c) Exit reader Push button request to exit Emergency exit break-glass

3.16.3

Push button request to exit as referred to in (b) shall record the exit in the event database. The button shall also break power to the lock to ensure safe exit. Entry and exit methods referred to in clauses (b), (c) and (c) shall each record the event in the event database. The door shall be monitored for both door open/closed and door unlocked/locked using concealed monitor switches appropriate for the door installation. Where the door is a double door, the inactive door leaf shall also be monitored for door open/closed and door unlocked/locked. The inactive leaf door monitor switches may be connected as part of the active door leaf monitoring. It shall be possible to configure the door in a way that generates a forced door alarm should the door be unlocked and/or opened without reference to the system. Should a door be left unlocked or open after a preset time (up to 9999 seconds), an alarm shall be generated reporting the condition. The door open/unlocked warnings shall provide an audible warning at the door. It shall be possible to disable the reader audible warning. It shall be possible to generate the audible warning via a relay connected elsewhere in the system.

3.16.4 3.16.5

3.16.6

3.16.7

3.16.8 3.16.9 3.16.10 3.16.11

17

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.16.12 Should a valid request to access a door be generated and access not taken, it shall be possible to ignore the request (not record it as an event) and automatically re-secure the door after a preset time. When a valid access through a door is undertaken, the door shall immediately re-secure on re-closing. It shall be possible to create an interlock relationship between a group of doors. Up to 20 doors shall be able to be included in any interlock group. It must be possible to configure interlock groups via GUI drag and drop functionality, without the requirement to write scripted logic. SYSTEM INTEGRATION The system shall support OPC (OLE for Process Control) Alarms and Events protocol to provide an open interface to allow integration with Building and Facilities Management, and Management Information Systems. The OPC Interface shall allow third party OPC clients to access the security systems events and field device data. The system shall provide an XML interface to allow for the import, export, and synchronisation of data in an ongoing basis from other applications directly into the Cardholder database both an on-line real time manner or in a batch oriented approach. A developer's kitset shall be readily available to allow for easy implementation. The system shall provide an XML interface to allow for updating access control schedules from other applications directly into the system configuration database both an on-line real time manner or in a batch oriented approach. A developer's kitset shall be readily available to allow for easy implementation. Access via OPC or XML shall be managed as operator events and logged accordingly. A facility shall be provided in the system to allow for the real-time export of any alarm or event information to 3rd party systems via customisable strings for the purposes of controlling the 3rd party application. The system shall support accepting events from one or more 3rd party applications and displaying these and their status in the event and/or alarm windows. Events from 3rd party systems shall be managed in the same way as inputs connected directly to the IFCs. ACCESS CARDS AND TOKENS The access token technology for this project shall minimally support Proximity 4Kb cards and the reader technology as specified in association with this specification elsewhere shall match. All Proximity cards, Vehicle Tags and Personal tokens shall be passive (without internal battery).

3.16.13 3.16.14 3.16.15 3.17 3.17.1

3.17.2 3.17.3

3.17.4

3.17.5 3.17.6

3.17.7

3.17.8 3.18 3.18.1

3.18.2

18

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.18.3 Access cards shall be of standard credit card size, being no larger than CR-80 and shall be direct printable using a dye-sublimation print process and be capable of accepting an adhesive label printed through such a process. All cards shall meet Australian (AS14443-2003 parts 1 to 4) and ISO standards for proximity and magnetic stripe encoding. Special mention is made again of the 128 bit AES encryption requirement. As well as CR80 sized cards, vehicle tokens and key-ring transponders should also be proposed as an alternative in special applications, where available. The access token data shall include: (a) (b) (c) A unique facility (site) code not used for any other system worldwide. A unique cardholder identification number at least 7 digits long. An issue level for each card number to allow for replacing lost cards without reducing the card database size. Up to 15 levels of issue levels shall be supported.

3.18.4

3.18.5

3.18.6

3.18.7 3.18.8 3.18.9 3.18.10 3.18.11

The access control token shall uniquely identify the cardholder to the access control system. Access control information shall be stored on or in the access token in a check-summed format. During transmission of data between a proximity access token and a proximity reader, the data shall be check-summed. All access control encoding data shall be invisible to the naked eye. There shall be barriers employed to prevent the deciphering of access control data stored on the card using any readily available equipment. The tenderer shall document the barriers used. There shall be barriers employed to prevent the copying or altering of access control data stored on the card using any readily available equipment. The tenderer shall document the barriers used. Additional cards and access tokens shall be available and delivered on site within 24 hours of request. Cards and access tokens shall be able to be encoded by the supplier and/or the University according to the specifications, made known at the time of order. Cards and tokens supplied with manufacturer determined card numbers will not be acceptable. It shall be possible to encode cards and tokens to allow operation of a user defined Personal Identification Number (PIN) in association with the card requirement specified in 3.18.14 and the card still be supplied ex stock as defined above. As an alternative, pricing should be supplied for the supply of encoding software and hardware that enables the University to encode our own cards and/or tokens on site.

3.18.12

3.18.13 3.18.14

3.18.15

3.18.16

19

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.18.17 3.18.18 3.18.19 The system shall provide facility to encode cards or tokens on an individual basis. The system shall provide facility to encode cards or tokens in batches of user definable quantity. Proximity card technology is specified: (a) 3.18.20 The card number must be a number specifically coded onto the card. It shall not be the card serial number (CSN). The cards shall incorporate a high coercivity (4000 Oersteds) magnetic stripe. The data shall be encoded onto Track 1 of the magnetic stripe.

For magnetic stripe technology as specified: (a) (b)

3.19 3.19.1

CARDHOLDER MANAGEMENT The cardholder database shall be structured so that the name field is the master field for each record. A background unique identifier may be used as the key field for each record but this must not be required by an operator to identify a cardholder. Use of the card number as the key field is not acceptable. Each IFC shall cater for the number of cardholders as defined in 3.10.8 and 3.10.9 above. The entire system should cater for at least 900,000 cardholders. The system must allow at least 15 Issue Levels per card or token to match that specified in (c) above. This must deny access and raise an alarm to the operator when a wrong issue level is presented to a reader. Cardholders must be able to be issued with more than one access token of different description and different number (i.e. access card and vehicle token) whilst maintaining only one cardholder record in the database. At least 64 user-definable Personal Data fields shall be provided which may be selectively reported on. PERSONAL DATA FIELDS Personal data fields shall be able to be set up as either: (a) (b) (c) (d) (e) Text Text List Numeric Image User data may be entered. User selects text from a pre-prepared list of text strings. User must enter numeric data. The field has a default value assigned. The field may only contain an image to the field. Data must be entered. Data must be unique from all other card records.

3.19.2

3.19.3

3.19.4

3.19.5 3.20 3.20.1

Default Value

3.20.2

Personal data Fields shall also be able to be configured as: (a) (b) (c) Required field Unique Values

No default Value Default value disabled.

3.20.3

A notes/memo field shall be available, associated with each card record. 20

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.20.4 3.20.5 3.20.6 The notes field shall support word-wrap, insert, delete, cut, copy and paste functions. It shall be possible to group or filter cardholders for the purposes of editing access, generating reports and assigning operator privileges. The following information fields shall be displayed on the Cardholder editing window: (a) (b) (c) 3.20.7 3.20.8 3.20.9 3.20.10 3.20.11 3.20.12 The date when a cardholder record was created. The date when the record was last modified. The date when the card was last printed.

For ease of programming Cardholders shall be grouped into access groups sharing the same access criteria and default personal data fields. It shall be possible to enter an automatic expiry date/time for the card. Automatic expiry or deauthorisation of cards not used for a predetermined period of inactivity of up to 999 days shall be administrator configurable. It shall be possible to allocate start and end dates and times for an Access Groups access to a particular access zone. Access shall have start and end dates and time to within one minute. The system shall be capable of importing and exporting database information, on selected cardholders, from other systems and be capable of exporting that cardholders data, either with or without controlled alteration or amendment, to other databases. Interface and data formats shall be clearly detailed. The system shall support the capability to allow bulk changes to card records. It shall be possible to carry out the following changes as a bulk change: (a) (b) (c) (d) (e) Delete selected cardholder records. Change personal data fields Change card details. Change access options Change the system division the records are assigned to.

3.20.13

3.20.14 3.20.15 3.21 3.21.1

A bulk change shall be able to be saved and scheduled to run at a later time. A window shall be provided to show details of created, saved, edited, pending, successful and failed bulk changes. PHOTO ID BADGING AND IMAGE MANAGEMENT The system shall provide a means to: (a) (b) (c) Electronically capture images. Store the images in a server database, Integrate those images into a pre-designed ID card from within the system 21

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 (d) Produce an integrated and completely finished identification card within the nominated time frame. Preference will be given to systems that provide a Wizard functionality for image and card production Photographic image of the cardholder Signature of the cardholder and/or authorising person A fingerprint of the Cardholder

3.21.2

Images are defined as being one or more of the following: (a) (b) (c)

3.21.3

The system shall have an integrated method of card design within the system software without the requirement of having to import background files from other software programs. The facility to import background images from other sources must also be available. This must include scanned logos and other graphical imagery if desired. The system offered shall capture images in 24 bit colour and at least 640 x 480 pixel resolution using standard video capture hardware offering a TWAIN or Direct Draw standard interface, or a USB digital camera. Images must be able to be cropped after capture to optimise the image size within the desirable image area. This movable cropping box must be user-definable as to size. Images must be capable of being enhanced from within the capture software after they have been captured, by the use of: (a) (b) Variable Contrast and Brightness controls Smoothing and Sharpening controls

3.21.4

3.21.5

3.21.6

3.21.7

The controls must be easy to use from within the system software and once set, they must be capable of applying the same setting on subsequent image captures for future cardholder records. The image, once captured, must also be capable of being flipped and inverted as required before being printed or stored as per clause 3.21.1. Up to three images per cardholder must be capable of being captured and stored within the system. Images may be defined as per section 3.21.2 above. The system shall store images in the JPEG compression format. User definable compression rates shall be easily selectable by the operator permitting, as a minimum; at least three levels of JPEG compression are required. The system offered shall be capable of importing and exporting image files, for use in either card layout or cardholder images, from at least the following formats: (a) (b) (c) JPEG Windows BMP TGA

3.21.8 3.21.9

3.21.10

3.21.11

22

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.21.12 The card design must be capable of incorporating, storing, printing and displaying bar-code information and must support the following bar-code formats: (a) (b) (c) (d) (e) (f) 3.21.13 Code 39 Code 39 with checksum Interleave 2 of 5 Interleave 2 of 5 with USS Interleave 2 of 5 with OPC Telepen

The system must have an integrated card design program. Systems offering a separate card design program where card design images must be created in alternate drawing programs and imported are not acceptable however the system offered must also be capable of using imported images as per clause 3.21.11. The card layout section of the system must be capable of user-selecting up to 16.7 million colours with a custom colour palette available. Card design must be accomplished by the use of drag and drop options using a mouse. The system must be capable of using all of the common word processing fonts and must also be capable of normal text manipulation including, text sizing, left and right justification, centred, bolding, underlining & italicising. The variable cardholder image files that are selected to incorporate into the card design must be user-definable as to capture and size. The sizing must be fully user-configurable from 25% of full size up to 200% of full size, as a minimum, and must offer automatic aspect ratio adjustment throughout the size range. Maximum resolution in pixels is to be stated in response to this clause. The system shall be capable of producing hard copy output of images and data using any standard MS-Windows printer. The system shall produce photo ID cards using a single step hard-card colour MS-Windows compatible printer. Datacard SP 75 is current unit. Systems offering multi-stage production, heat lamination or heat & pressure card production are not acceptable. The system shall be capable of printing directly onto Hi-Co magnetic stripe cards, Wiegand effect cards and proximity cards without damaging the card technology. Cards must be capable of either landscape or portrait printing and Barcodes must be capable of either vertical or horizontal orientation on the card when printed. OPERATOR MANAGEMENT The system must provide for at least 500 operator groups. Operators shall be members of operator groups. 23

3.21.14 3.21.15 3.21.16

3.21.17

3.21.18 3.21.19

3.21.20

3.21.21

3.22 3.22.1 3.22.2

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.22.3 3.22.4 3.22.5 3.22.6 Operator establishment and maintenance shall be limited to assigned Senior Operators. It must be easy to define operator privileges for a group of operators and it must be easy to add an operator to the group. Operator access to the system is to be restricted by means of an operator identifier and individual password. Passwords shall be managed by using either non-restrictive or force password changes. Forced changes shall include options for: (a) (b) (c) (d) (e) 3.22.7 3.22.8 3.22.9 3.22.10 Minimum password length greater than 8 characters. Mixed case characters Mixed alpha and numeric characters Change password after a defined period of up to at least 365 days. Remembering and rejecting at least 8 previously used passwords.

Each operator shall have the authority to alter his own password, but not that of other operators Automatic logoff shall occur after a preset time of up to at least 60 minutes of operator inactivity. It shall be possible to configure the system to only allow one logon per operator. It must be possible to allow or deny Operators access to system menu functions, including viewing of Cardholder Personal Data fields, Personal Notes and Images. It must be possible to restrict Operator access to Cardholders based on system division. It shall be possible to assign different access rights for each division an operator is required to access. For example, advanced user for division 1; view only for division 2; and no access for division 3. Any menu option not available to an Operator should be either greyed out or not visible. Tenderers will provide full details of the operator filters or function limits available to the system administrator within the system. ELEVATOR CONTROL AND MANAGEMENT The system must provide fully integrated elevator control facilities. The elevator control access equipment must communicate with the same central control as the door card readers. The elevator control architecture shall comprise a card reader in each elevator car, reporting to elevator control interface equipment mounted in or near the elevator motor room. Reader type shall be as specified for use on access control doors. The elevator control system shall be capable of controlling access independently in a number of elevator shafts simultaneously. 24

3.22.11 3.22.12

3.22.13 3.22.14 3.23 3.23.1

3.23.2

3.23.3

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.23.4 3.23.5 The elevator control system shall incorporate dedicated intelligence and a local database of authorised cardholders. Each elevator reader shall be identified independently at the central control by means of a unique plain language descriptor. The central control plain language descriptor shall be at least 60 characters in length. Each reader head shall be capable of raising an alarm if it stops communicating with its elevator controller or is removed from the elevator. The elevator control shall check entry based on ALL of the following criteria: (a) (b) (c) (d) (e) (f) 3.23.8 Correct facility code Authorised card in database Correct issue number Authorised level Authorised time of day Correct PIN (If PIN entry is required).

3.23.6 3.23.7

The access mode for each elevator shall be capable of automatically changing according to the programmed time schedules, as received from the central control. The following access criteria modes are required: (a) (b) Free access - Elevator level select button for that level is unlocked, no card entry required. Secure access - Elevator level is locked. A successful card attempt is required for valid entry. Elevator level re-secures after access attempt. Secure + PIN access - Elevator level is locked, a successful card and correct PIN number attempt is required for valid entry. Elevator level re-secures after access attempt. Dual Authorisation - Access is granted when two different but legitimate cards are presented within a given time frame. Escort - A second card is required to be presented from a cardholder who is nominated in the Escort Access Group. Shared PIN Number - the system Operator determines what the PIN number will be and programs this into the system. Access is allowed at the elevator level when the correct 4 digit PIN is pressed followed by the Enter key.

(c)

(d) (e) (f)

3.23.9 3.23.10 3.23.11

The elevator control system shall be capable of individually setting the access modes for each level as described in 3.23.8. Levels must be securable on a level-by-level basis, using command instructions transmitted from the central control. The central control must provide operator override facilities to enable temporary override capability on a level by level basis.

25

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.23.12 The elevator control system shall continue to operate without performance degradation in the event of a communications link failure with the central control. LOW LEVEL INTERFACE (WHERE SPECIFIED) The interface between the access system elevator control equipment and the actual elevator switching control equipment shall be via dry relay contacts. The voltage from the elevator system connected to the relays shall not exceed 24 volts DC/AC The elevator control system shall provide one relay contact per elevator shaft per level for the system. This relay contact shall be used to interface with the elevator switching control equipment. An input shall be provided for each level per elevator to indicate what level the user selected. On activation of this input all relays return to secure state. HIGH LEVEL INTERFACE (WHERE SPECIFIED) The interface between the access system elevator control equipment and the actual elevator switching control equipment shall be via RS-232 connection. The elevator control equipment will provide feedback as to which level was selected by the cardholder and only allow the one level to be selected per valid card swipe. INTRUDER ALARM SYSTEM The system will incorporate a fully functional intruder alarm system. All Inputs globally within the system must be able to be utilised as intrusion alarm inputs to allow intruder detection sensors to be connected to the system. All outputs anywhere within the system shall be available for intruder alarm purposes such as sounding remote sirens etc. Arming and disarming the intrusion detection system shall be by either using card readers or remote arming terminals. The intruder alarm zone and the access zone for an area shall be treated as separate conditions. The intruder alarm system shall provide a dependency feature where by an alarm zone does not go into the set state until the Dependent alarm zones are all in the set state. If the alarm zone is set (armed) and the access door is secure: A cardholder shall require authorisation to both unset (disarm) the intruder alarm zone and to access the access zone, to be allowed access. If the card is not authorised to unset the alarm zone or not allowed to access the access zone, then access shall be denied. If the alarm zone is unset (disarmed) and the access door is secure: 26

3.24 3.24.1

3.24.2 3.24.3

3.24.4

3.25 3.25.1

3.25.2

3.26 3.26.1 3.26.2

3.26.3 3.26.4 3.26.5 3.26.6

3.26.7 3.26.8 3.26.9 3.26.10

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.26.11 3.26.12 3.26.13 3.26.14 3.26.15 A cardholder shall require access to the access zone only for access to be allowed. If the card is not authorised to access the access zone, then access shall be denied. For normal operation, after an authorised card is presented, and access is granted, then the alarm zone shall remain unset after the door relocks. As an optional function, the alarm zone must auto-set after a predetermined time period. When specified, alarm monitoring shall use a connection with Central Alarm Monitoring stations via digital communicators using Contact ID format, connected directly to the IFC panels. It must be possible for alarms from one IFC to be managed on a second IFC where the digital communicator is installed. (Peer to Peer communications). Digital communicators are to be able to communicate alarms from the complete system, independent of system server. The system shall report and log the all Digital Communicator activity and reason for any failure to communicate. The system shall provide for up to two back up diallers on different controllers to provide automatic backup capability should the designated digital communicator fail to operate on the appropriate alarm condition. Cardholders shall be assigned to groups, to which any combination of the following intruder alarm privileges relating to the operation of the system may be assigned: (a) (b) (c) (d) (e) (f) (g) 3.27 3.27.1 3.27.2 Unset intruder alarm zones Set Intruder alarms zones View the status of alarms and inputs on Remote Arming Terminal. Acknowledge Alarms Shunt Inputs Force-arm alarm zones Auto-isolate alarm zones

3.26.16

3.26.17 3.26.18 3.26.19

3.26.20

INPUT AND OUTPUT CIRCUIT FUNCTIONALITY Input circuits shall be connected to the IFC as described in clause 3.10.10. Inputs from detection devices covering the same region for control purposes are to be grouped into alarm zones. Alarm zones can be in any one of four states and shall handle alarms differently depending of the state. The first two shall be defined as set (armed) and unset (disarmed). The names of the other states shall be able to be defined at the central control for other purposes such as maintenance testing. Alarm priorities can be assigned to any of the four input states. 27

3.27.3

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.27.4 3.27.5 3.27.6 The system shall provide entry and exit delays for the setting and unsetting of alarms. The entry delay shall be configurable from 0 to 5 minutes in steps of one second. An optional audible warning must sound during the entry delay (from the time that the alarm occurs to the time that the Zone state is changed). It must be possible to designate specific card readers and remote arming terminals to sound entry delay warning beeps. Selected output relays should also be able to be operated during the entry delay period allowing suitable sounders to be connected at required locations. An exit delay is to be provided to groups of inputs so that a change of state of an exit delayed zone is delayed by the exit delay period, which can be adjusted, from 5 seconds to 5 minutes in steps of one second. An optional audible warning must sound during the exit delay (from the time that the alarm occurs to the time that the zone state is changed). It must be possible to designate specific card readers and Remote Arming Terminals to sound exit delay-warning beeps. Selected output relays should also be able to be operated during the exit delay period allowing suitable sounders to be connected at required locations. This applies to both manually and automatically changing the state of a zone in the case of automatically changing the state of a zone the exit delay and audible warning gives people working late in the building time to unset the alarms or leave the building. The system shall include Alarm Escalation as an event. The new event shall correspond to the original alarm, but may have a different (usually higher) priority, and may require a different set of alarm relays to operate. Escalated alarms shall be able to be displayed in a Window specifically provided for this purpose. Alarms shall be able to be escalated under the following conditions: (a) (b) (c) (d) (e) 3.27.12 3.27.13 Escalate if alarm not acknowledged after (X) seconds Escalate if in inactive state for (X) seconds Escalate if zone contains (X) alarms Escalate if two event from same point within (X) seconds. Escalate if two events from different points in same zone within (X) seconds

3.27.7

3.27.8

3.27.9

3.27.10 3.27.11

It shall be possible to have automatic time based setting and unsetting of alarms. It shall be possible to configure the system such that events (such as a card swipe or operation of a key switch connected to an input) can change the state of a zone. Authorised cardholders shall be allowed to set and unset alarm zones by: (a) Operation of the Card plus PIN reader as an alarm panel.

3.27.14

28

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 (b) Presenting a valid access card to a card reader associated with the alarm zone, twice within a nominated time period (double card badging).

3.27.15 3.27.16 3.27.17 3.27.18

It shall be possible to set and unset multiple alarm zones from a Remote Arming Terminal. All alarm occurrences shall be presented at the central control within 4 seconds of their occurrence at the remote field device. All Alarm events shall be viewable from an Alarm Stack. It shall be possible to view all alarm events by clicking on interactive Site Plan icons that, because of their changing audible and visual states, indicate the presence of alarms. All alarm events arriving at the central control shall be "time stamped" with the time they occur and the time they were logged at the central control. All alarm events shall have a user definable alarm priority assigned. A minimum of 8 alarm priority levels plus non-alarm event and ignored shall be provided. It shall be possible to assign a different audio warning sound to each alarm priority. Incoming Alarms shall be presented in the Alarm stack according to their assigned priority with the highest level at the top. Alarms with the same priority shall be presented in time order. The priority of Alarms in the alarm stack shall be identifiable by a different text colour. Identical consecutive alarms that occur within a predefined time span shall be report as a single alarm with the number of occurrences reporting as a flood alarm quantity. The central control must be able to control the actual priority assigned to any alarm activation throughout the day. This means any alarm activation may be programmed as "Low Priority" during office hours and "High priority" at all other times. It shall be possible to nominate an Input (e.g. Smoke, Fire or Gas detection) as an Evacuation Input in which case certain doors within the Site will revert immediately to Free Access. Operators shall be required to complete 2-stage alarm processing as: (a) Acknowledge Alarm. (i) An Acknowledged alarm shall remain in the alarm stack and be easily identified as having been acknowledged but not yet processed. The central control shall record in the hard disk activity log that the operator has acknowledged the alarm. An alarm is acknowledged by the operator selecting the Acknowledge button in the alarm-viewing window.

3.27.19 3.27.20

3.27.21 3.27.22

3.27.23 3.27.24

3.27.25

3.27.26

3.27.27

(ii)

29

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 (iii) (b) A second alarm from the same source as the acknowledged alarm shall be indicated as a new alarm. A Processed alarm shall clear from the Alarm Stack. The central control shall record in the hard disk activity log that the operator has processed the alarm. An alarm is processed by the operator selecting the Process button that is displayed in the alarm viewing window.

Process Alarm. (i) (ii)

3.27.28

An active alarm shall not be able to be finally processed and cleared from the Alarm Window until the cause of the alarm has been removed and the alarm condition has returned to the normal state. Pre-programmed alarm instructions shall be available for the operator to provide instructions for acknowledging and processing each alarm. Alarm Instructions shall have the following features: (a) Default Alarm Instructions shall be able to be programmed and automatically applied to all events of a common type e.g. all wrong PIN events applicable to all readers. Individual Alarm Instructions shall be able to be programmed and applied to individual alarm events.

3.27.29 3.27.30

(b) 3.27.31

A table of contact names, phone numbers or other frequently used volatile information shall be available when programming Alarm Instructions, and applied to Alarm Instructions from a pick list. When items in the pick-list are updated, the linked Alarm Instructions shall automatically update. The alarm instruction text shall be able to be formatted using common text formatting features including but not limited to: (a) (b) (c) (d) (e) (f) (g) Bold, italic and underline Text colours Left, centre and right justified. Bulleted text Standard Microsoft Windows font types and sizes. It shall be possible to copy and paste Alarm Instructions between alarm events. The Alarm window shall allow the operator to enter a comment. Such comment will be date/time stamped by the system, and recorded against that alarm event in the audit trail. The system shall provide relay output facilities that are system activated in response to alarm activations. Relay functions required are: Activate and latch a relay in response to an alarm. Relay to remain latched until alarm processed. 30

3.27.32 3.27.33

(h)

(i)

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 (j) (k) (l) Activate a relay for pre-set "pulse" time. The relay to release after the "pulse" time lapses. Relay activation to "mirror" or follow the alarm input activation. The system shall incorporate relay outputs that can be activated according to time schedules, rather than alarm event. These outputs may be used to control lighting, heating, or to electronically lock or unlock non-monitored doors.

3.28 3.28.1 3.28.2

REMOTE ARMING TERMINALS Remote Arming Terminals (RATs) shall be provided to allow keypad functionality as described in this section. Logging on to the RAT functionality shall be by: (a) (b) (c) A User Code (PIN) assigned to each cardholder. Presenting a card to a reader associated with the Remote Arming Terminal. Presenting a valid card to a reader associated with the Remote Arming Terminal plus entering a 4 or 6 digit PIN on the Remote Arming Terminal. Set and unset all or selected intruder alarms zones that have been assigned to a Remote Arming Terminal. Acknowledge alarms. Shunt inputs for alarm zones. View a summary of status of all devices associated with the RAT. See and operate on the appropriate alarm zone information they have access to.

3.28.3

Authorised cardholders shall be able to: (a) (b) (c) (d) (e)

3.28.4 3.28.5 3.28.6

Cardholder and groups of Cardholders shall be able to be assigned to operate any number of Remote Arming Terminals across a system. Communications between the Remote Arming Terminals and the controllers shall be encrypted to a strength equivalent to 40 bit Triple AES. Remote Arming Terminals shall be capable of being programmed to handle combination of up to any 30 alarm zones and up to 100 of their associated Inputs across a complete system. Multiple remote arming terminals can be used anywhere in the system to remotely manage assigned Intruder alarm zones. AUDIT TRAIL The Server hard disk shall be used to record all system activity for archiving purposes. It shall not be possible to alter archived data. Every system activity event along with all details, including but not limited to the following list, shall be time stamped with the time of occurrence to the nearest second and shall be recorded in the system activity log for archiving: 31

3.28.7 3.29 3.29.1 3.29.2

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 (a) (b) (c) (d) 3.29.3 All access attempts (allowed and disallowed). Alarm events. System events. Operator activity.

The central control shall provide an on-line facility to archive system data and event records to an archive file to free hard disk space for further activity logging. The archive process shall be initiated by either manual operation or automatically by time. It shall be possible to nominate the number of days of data that shall remain on the server subsequent to an archive process. REPORTS The central control shall provide historical reporting capabilities from the following sources of information: (a) (b) (c) (d) (e) System activity data Cardholder's access Cardholder Personal Data fields Cardholder access groups Site configuration and setup data.

3.29.4 3.29.5 3.30 3.30.1

3.30.2

The report generation feature shall be easy to use and based on a wizard style of parameter selection and preparation. The wizards shall provide features to simplify report generation by incorporating selections such as report for yesterday, last week, last month etc. This is for the purpose of quickly generating recurring, standard format, reports. The parameters for producing the report must be fully user definable and must be capable of searching on any cardholder or access event criteria. It shall be possible to produce an Evacuation Report upon request that will list all cardholders by their last known Access Zone. The central control shall generate and format reports in "background". This means the operator must be able to process alarms, alter database parameters and perform other system changes while the report is being generated. Report generation must continue if the operator decides to perform any other task. The central control shall have a screen preview function, so that reports can be previewed on-screen before they are printed. Report formats shall be able to be saved for future use. The central control shall have a "printer spooler" so that reports can be printed at any network-supported printers connected to the system. The central control shall have a printer queue facility to enable reports to be queued if the target printer is off-line, busy, not connected or faulty.

3.30.3 3.30.4 3.30.5

3.30.6 3.30.7 3.30.8 3.30.9

32

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.31 3.31.1 GUARD TOUR PROGRAM AND REPORTING Guard Tour shall be a programmable functionality through a system window GUI which allows simple pick and place construction of the items making up the tour. The basic functions shall meet or exceed the following minimum performance specifications. A minimum of four (4) alternate routes during a set time period, with the start time being activated at any time by the Security Officer entering his/her start time at the security control room computer. All card readers located in and around the building, shall be capable of being assigned within a Guard Tour sequence, using both entry and exit times to track a Security officer throughout the entire route as programmed by a Shift Supervisor/System Administrator. Should any intermediate timer expire due to any failure of the Security officer reaching his next assigned card reader, an alarm shall be raised and logged onto the Access Control System and also through program selection send the alarm to the system printer. Guard tour times shall be programmable by the system administrator in minutes and cater for both internal and external areas of the campus. The guard tour function shall allow for a minimum of 50 guard tour routes, for 10 Security Officers covering a minimum of any of 100 readers, with a minimum of 4 tours being active at any one time. The guard tour function shall log all Guard tour transactions at nominated readers and shall report both too early and too late calls to the system and alarm to monitor screen and printer if selected when the tour route is actioned out of sequence or when the time taken to reach any reader point exceeds the predefined total time by a predetermined time. This time shall be programmed prior to the commencement of a tour and be accessed only by authorised access levels. The guard tour function shall produce detailed printouts of sequenced readers to be followed by the Security officer in carrying out his tour and precise logs of all his recorded actions (i.e. attendance at each card reader). The reports shall also include all times taken between each reader within any tour and include any alarms made during a tour. All reports shall be displayed on the administrator terminal with options to print all details to the system network or local printer. The Security Management System shall be configured such that an entry and exit door is assigned a guard tour point for recording the guards arrival and departure time to all buildings. COMMUNICATIONS & DIAGNOSTICS The central control shall automatically restart full and complete processing after a power failure. The central control shall provide a full diagnostic performance log to enable system engineers to monitor system performance in the event of a system malfunction.

3.31.2

3.31.3

3.31.4

3.31.5

3.31.6

3.31.7

3.31.8 3.31.9

3.32 3.32.1 3.32.2

33

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 3.32.3 3.32.4 3.32.5 The diagnostic performance log shall be stored in a separate file on hard disk from all other data files. The diagnostic performance must be available without shutting down or "freezing the system". The central control shall provide on-line system diagnostic facilities which enable authorised operators or systems engineers to monitor and then tune the system performance (communications network performance tuning, for example). Installation Specifications PRE-CONNECTION DOCUMENTATION Before any door controllers and networked devices are connected to the Campus wide access control server system the documentation must be provided at least two weeks prior in each case. Documentation shall show the status of all units and inputs connecting to the hardware, this will prevent any alarms congesting the Security Console. This requires the contractor to be responsible for testing the hardware prior to connecting to the ANU network. If the units or inputs cannot be sealed then other means must be provided to prevent the alarms from occurring until after completion of the project. Minimum requirements (a) (b) (c) (d) 4.1.6 5. 5.1 5.1.1 Controllers MAC address, description, location and tamper status. Power Supplys Circuit Breaker Number, and location. Door Descriptions, reader status e.g. connected Input descriptions, current status [should be sealed] and proven means of testing e.g. resistance value.

4. 4.1 4.1.1

4.1.2

4.1.3 4.1.4 4.1.5

ANU Security can provide samples of documents I and J relating to preconnection documentation. Cardax ACCESS CONTROL HARDWARE All access control equipment shall conform to the specification contained within the tender document issued by the University or its approved agent. READERS All readers installed on campus in new installations are required to be: Cardax (or approved equivalent) Mifare Plus Prox Readers (noting the interim magstripe arrangements for 2010). DOORS

5.2 5.2.1 5.2.2 5.3

34

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 5.3.1 All access control or TCR doors in the tender will be supplied with the appropriate ANU Numbering system on engraved trefolite adhesive labels [one label per reader]. Doors under the control of the ANU access control system shall be installed and programmed to provide and be monitored for the following signals. (a) (b) (c) (d) (e) (f) 5.3.3 5.3.4 Forced Door Door Open Door Open to long Lock or Bond Sense Individual break glass alarm Auto door controller fail

5.3.2

Successful contractor will advise the Project Officer of any door condition that may affect the performance of the access control system. This shall include but limited to: (a) (b) Door Furniture Door Frames

5.3.5 5.3.6

New aluminium doors shall be made to the ANU aluminium door specification NOTE: Any door required for fitment with access control shall have a clear height minimum of 2100mm prior to installation of the electronic lock. This specification allows clearance for the mag lock on the secure side of the door. See also Clause 8 Aluminium Door spec for more detail. Locks LOCK TYPES The locking devices controlled by these systems shall be either the Magna lock type or the Padde ES2000 type. Some variations may be encountered (e.g. automatic doors etc) but must be approved in writing by ANU Security. Padde EML6 for single leaf doors. Incorporating bond sense, LED on lock and 1500 LBS holding force. Padde EML10 for double leaf doors. Incorporating bond sense, LED on lock and 1500 LBS holding force. LOCKING STYLE All locks shall be the fail to safe type. (power on to lock) All Magna locks shall be fitted with tamper proof screws if on the non secure side and to include appropriate mounting equipment for inward and outward swing doors. All Electric strikes shall be fitted with a diode across the coil to reduce Back EMF. Strikes shall also have high strength striker cover plates 35

6. 6.1 6.1.1

6.1.2 6.1.3 6.2 6.2.1 6.2.2

6.2.3

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 securely mounted to protect the tongue and lock mechanism from being forced or manipulated. 6.2.4 All locks shall be installed in a tradesman like manner. Mag locks (unless otherwise approved) shall always be installed on the secure side of a door. An Additional manual lock set will be provided (where none pre-exists) to ensure that the door can be secured should the access or power system fail [cylinder and key format to be specified by the ANU]. BREAK GLASS UNITS All electric locks installed must have a Green break glass unit mounted adjacent to the door at 900-1200 AFFL. Fracturing/breaking the glass or plastic must initiate a direct break in lock power to allow free egress and produce an individual alarm on the Command Centre e.g. Glass broken. The break glass (Green) shall be key resettable dual pole units utilising clear plastic inserts. Note: The initiation of free egress via communication input is not permitted in meeting this specification. AUTO FIRE TRIPS An interface to the building fire system is necessary to initiate the unlocking of all electric locks that internally lead to and include emergency exits in the event of a fire Alarm. This interface must be made to all connected fire systems including sprinkler and Fire Indicator Panels [to the bell output only]. The interface will activate by the following - all lock power supplies will pass through a relay contact, which will be controlled by the fire system/s and shall be the two-pole type. The second pole will be used to monitor the state of the fire relay and shall be programmed to activate an alarm input on the campus wide access control system. The commissioning tests shall ensure full compliance with this specification and also test the operation of the fire activation circuit including all other functionality tests on all manual and auto doors designated as emergency exits to further confirm compliance. REED SWITCHES Sentrol type flush type 19 or 25mm Only be surface mount where flush mount is not suitable. POWER SUPPLIES Low voltage power supplies shall be self contained and installed within the secure equipment cabinets as per clause 11.8. The power supplies shall be a switch mode with a minimum capacity of 2 amps and shall have stand by batteries capable of sustaining continuous operation for at least 8 hours in the event of a mains supply failure. Power supplies to incorporate mains fail and battery low indications. 36

6.2.5

6.3 6.3.1

6.3.2 6.3.3 6.4 6.4.1

6.4.2

6.4.3

6.5 6.5.1 6.5.2 6.5.3 6.6 6.6.1

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 6.6.2 6.6.3 6.6.4 All Power supplies will be Austel Approved 240V/12VDC All power supplies must have their mains and battery condition monitored and shall activate an alarm on the Cardax or equivalent System if a problem occurs for example loss of mains [240volt] and or low battery alarm. All power supplies installed shall not have more than 65% current drain. For additions to existing systems current draw shall not exceed 80% before new additional power supplies should be allowed for. The ANU prefers the use of linear power supplies to reduce any possible interfaces to the Facilities electronic equipment used in high technology buildings. Tenderers offering other types of power supplies shall provide technical details to allow evaluation and assessment of their suitability for installation at the University. The minimum specifications as above shall be utilised when supplying linear units. Details must be provided in the material list of the capacity and type of each power supply included to meet the tender requirement Power supplies shall be scaled up in output capacity so as to have the ability to recharge the connected battery/s from a fully discharged condition without tripping or failing. BATTERIES EDAM BA006 (or equivalent) minimum 12 volt 7amp/hr capacity (sealed unit) Hold System and Locks working for minimum 8 hours at time of commissioning. Be monitored by the power supply for Low battery alarm. Battery capacity scaling shall be considered in lieu of multiple minimum sized units. EQUIPMENT CABINETS Rittel or equivalent. (samples may be requested). All equipment cabinets are to be tamper monitored to both the door and to the rear-mounting surface. All wiring inside the enclosure shall conform to Australian standards and the ANU electrical specifications. TIME CONTROLLED ACCESS DOORS [TCR] All Doors installed without readers will comply with section, 10.3 Doors Each TCR will have the reader cable installed and located above the door for future reader connection.

6.6.5 6.6.6 6.6.7

6.6.8

6.6.9 6.6.10 6.6.11

6.7 6.7.1 6.7.2 6.7.3 6.7.4 6.8 6.8.1 6.8.2 6.8.3 6.9 6.9.1 6.9.2

37

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 6.9.3 6.10 6.10.1 6.10.2 6.11 6.11.1 Hardware allocation should allow for the future connection of the reader to the system. REQUEST TO EXIT BUTTON Any exit buttons specified will meet Australian disability standards for location and operation. The request to exist button shall be an approved button assembly equivalent to the EX16 specification. SECURITY ALARMS Within the ANU Campus there were two options for installing alarms systems, the first is to utilise the Cardax (since the advent of the RAT in FT) and the second is the stand alone alarm system. It is the Universitys intention to replace the stand alone security/intruder detection panels with an integrated access control and intruder alarm system. For alarm system indication there are a minimum of two approved means (a) (b) 6.12 6.12.1 Remote Arming Terminal indication (RAT) or equivalent Red indicator located above the reader

6.11.2

CARDAX SYSTEM OR EQUIVALENT INTRUDER SYSTEM Connection to a RIO with security devices such as detectors or reed switches. These devices will be set up with an alarm zone that can be controlled by a reader and or a Remote Arming Terminal [RAT] and or a Schedule [timeframe]. The University will assess the capability of the intruder component system as mentioned elsewhere in relation alarm management and the functionality for remote arming and disarming SECURITY PANEL OPTION. The University reserves the right for site installations with specific needs to retain the separate panel installation in such sites on campus the equipment shall be: (a) Remote Arming Terminal (RAT), C& K Sierra Type or approved alternative.

6.12.2

6.13 6.13.1

6.13.2 6.13.3 6.13.4 6.13.5 6.13.6 6.14

Shall supply a normal contact that can interface into the Cardax or equivalent System Have only 1 detection device per zone (unless otherwise approved by ANU Security) Shall not have its installers combination code changed from factory default. Shall be supplied with both User & Installers Manuals and all master codes to allow the University to reset systems and panels as required. Installation Manual will be supplied with all program changes from factory default noted. GLASS BREAK DETECTORS 38

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 6.14.1 6.14.2 6.15 6.15.1 6.15.2 6.16 6.16.1 6.17 6.17.1 Dual flex/audio detection separate microphone Minimum 7.6 metre detection range DETECTORS Dual Technology PIR & Microwave Selectable pulse count and walk test facility DURESS BUTTONS They shall be of the DURE001 PAB 11-117 Holds Up with Centre Push; they must lock on and be able to be reset manually through use of a key. WIRING REQUIREMENTS Cable requirements: (a) All wiring shall conform to the requirements the ANU Electrical Specification (RFT Attachment R) and AS 3000, Austel and ACTFB standards and codes. All surface wiring systems shall be approved by the ANU Security Management before installation. All power cables to locks and Cardax or equivalent units shall be .75mm minimum with due consideration given to voltage drop when calculating installation cable choices. All alarm monitoring cable shall be a minimum of .40mm All communications to readers and Cardax or equivalent units shall be twisted, shielded cable as specified on the drawings. All cables shall be labelled with suitable descriptions as to their opposite termination. All Cable labelling shall match a supplied cable termination Schedule All cable runs shall be concealed where possible and where not possible shall be installed in conduit or ducting in a tradesman-like manner as to A.S. 3000 No joins are to be made in any cable runs and all cable shall only terminate at system devices. Cabling shall not be laid on any ceilings and shall be supported throughout its length. All multicore cables shall have a minimum of two spare pairs unless otherwise specified. Cables shall be appropriately labelled at both ends. e.g. Critchley or equivalent.

(b) (c)

(d) (e) (f) (g) (h)

(i) (j) (k) (l)

(m) Supply and install dedicated (secure) 240v mains supply for all equipment from nominated distribution boards. Liaise with Superintendent for appropriate locations and availability. Where the cabinet is to be located in an insecure environment the GPO shall be housed within the cabinet and electrically isolated from the cabinet structure. The Project Manager shall evaluate the option of using a 39

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 non conductive cabinet in such installations and agree on the suitability or otherwise with the contractor. 6.18 6.18.1 CONDUITS Internal (a) (b) (c) (d) (e) (f) 6.18.2 (a) Shall be rigid LD-UPVC. Minimum 25mm diameter. All fittings draw boxes, bends and couplings are to be purpose made. Shall be joined using an approved solvent cement. Shall be secured using metal saddles spaced at 600mm (maximum) centres and within 150mm of all fittings. Shall be installed so that cables can be drawn in at draw boxes only. Inspection elbows shall not be classified as draw points. Shall be filled with cables to not more than 60% of its capacity. All conduits installed externally of a building shall be steel conduit (plated or painted depending on environment) to prevent tampering and shall meet all other specifications as Clause 11.18.1 (b) & (d). All visible conduit and duct routes shall be identified prior to installation by the contractor and approved by the superintendent. Cable Duct Shall be fitted with removable covers. Shall be fitted with the manufacturers standard bends, elbows, couplings and reducers. Shall be manufactured from extruded PVC when exposed. When concealed cavities and ceiling spaces maybe metal. Shall be filled with cables to not more than 60% of its capacity. Shall not be used on external building installations Shall comprise corrosive resistant metal thread screws or bolts into expanding type masonry anchors for fixing to concrete or masonry. Shall comprise tapered woodscrews for fixing to timber. (Full thread). Shall comprise metal expanding anchors for fixings to gyprock. All fixings to be corrosive resistant.

External

(b) (c) (d) (e) (f) (g) (h) 6.18.3 (a) (b) (c) (d) 6.19 6.19.1

Fixings

EXTERNAL READER FIXING AND INSTALLATION RATING All card reader installations on buildings and facilities (including under awnings, verandas, porticos, under crofts etc) shall meet or exceed an IP65 rating. The specification includes the penetrations and cable connections for the reader installation. 40

6.19.2

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 6.19.3 7. 7.1 Tenderer shall warrant this performance in accordance with the tender requirements. NETWORK AND 240 VOLT CONSTRUCTION AND RESPONSIBILITY BACKGROUND

The University builds and supports its campus IT Network and electrical reticulation in buildings. The access control system currently operates in a virtual private network with a University controlled IP range. The network resides behind a University administered firewall. Power over Ethernet is available in some part of the network. Cabling and Ethernet wall plug installation is managed by Network Services within the University Division of Information. University approved contractors will carry out the physical installation. 7.1.1 Tenderers are advised that they will be required to advise the University of the location requirement for Ethernet ports in each building or facility, where none are already installed or provisioned. Tenderers may quote pricing to install Ethernet ports into the University Network by university approved contractors. Full details of the pricing model shall be provided to allow detailed assessment. Network cabling shall comply with the ANU structured cabling specification as attached. Note that Ethernet cables shall comply with CAT6 category and specifications. All 240volt supply and outlets provided as a component of the tender shall be itemised on cost per a set point basis. The University shall retain the right to install any required GPO itself or optionally approve the contractor to install against the submitted schedule of rates (for GPO outlets). ALUMINIUM DOOR SPECIFICATION

7.1.2

7.1.3

7.1.4 7.1.5

8.

(This Clause is for Architect and Project Manager reference purposes - required in new and refurbishment projects) 8.1 8.1.1 8.1.2 BACKGROUND The aim of this specification is to ensure the construction of a door that will withstand the rigours of operation in a University environment. The door may be subject to several thousand cycles a day. Operation will be under access control which means the door could be in secure mode up to 24 hours every day. Locking will be either via magnetic lock (EML) or electric strike (ES). Under the operation of an EML the door is subjected to significant bending stress and possible abuse as a result of persons pulling on the door whilst the EML (at the head of the door) is still powered up. The design specification allows for adjustment and tensioning due to wear and tear. 41

8.1.3 8.1.4

8.1.5

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 8.2 8.2.1 8.2.2 8.2.3 8.2.4 PROFILES Doors shall be constructed of the Capral 249 Super line extrusion profile or equivalent. Top and Bottom Rail shall be a minimum 140 mm deep. Mid Rail shall be a minimum of 190 mm deep. Wall thickness of all extrusions shall be submitted for approval to the Project Co ordinator and ANU Security Management. Typically 3.2mm would be considered minimum thickness. Reinforced fixing to the door stiles shall be provided. CONSTRUCTION. The mid rail shall also have a 10 mm threaded rod (with a galvanic coating to avoid electrolysis) through its centre attaching it to the stiles via reinforcing blocks and threaded lock nuts. The nuts shall have washers of suitable size and thickness beneath. Tensioning access shall be provided via access holes (of a size suitable for a socket head wrench) in the edge of each stile. The access hole shall be covered with a press in plastic plug of neutral colour. A minimum of three (3) hinges shall be used per door leaf. Hinges shall be McCallum 104 type. Reinforcing plates shall be provided in the jambs for attachment of the hinges. The top and bottom rail shall be bolted to the door stiles using nylon lock nuts and the bolt reinforcing blocks shall fit snugly within the rail extrusion. Dorma TS83F hydraulic door closers shall be used and fitted to the internal side of the door. Contractors who have not supplied a door of this specification to the ANU previously shall provide a sample of their construction quality for approval. A completed door shall be viewed by the Project Co ordinator prior to installation. DOOR HEIGHT. All exterior doors and internal doors that could be fitted with access control shall have a minimum clear internal door height of 2100mm. This height allows for the fitment of electromagnetic locks. Maximum height for these doors shall not exceed 2400mm. CONSTRUCTION PROGRAM With the Tender documentation provide a construction program that indicates all major activities and milestones, which are necessary for completion of the works.

8.2.5 8.3 8.3.1

8.3.2 8.3.3 8.3.4 8.3.5 8.3.6 8.3.7 8.4 8.4.1

9. 9.1.1

42

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 9.1.2 Include dates for completion of significant stages of each major activity of the works such as shop drawings, placing orders, manufacturing, delivery, installation on site, placing into operation, adjustment, testing and such dates will be referred to as the Construction Program in the contract. PROTECTION OF PROPERTY AND EQUIPMENT AND FINISHES - REFURBISHMENT For the duration of the contract the Contractor shall take all necessary precautionary measures and ensure their continued efficiency, to protect all the Principals property, as well as that belonging to, or vested in, statutory authorities and private persons, companies, institutions, clubs, etc, against loss, theft or damage resulting from negligence by the Contractors personnel or that of his subcontractors and agents. All repairs are to be to the satisfaction of the principal All equipment, whether supplied under the contract or existing, at the site and surroundings, likely to be damaged or affected by ingress or deposit of foreign matter resulting from the Contractors operations or those of their Subcontractors or agents, shall be protected by the Contractor in an approved manner. Such protection shall be maintained in a satisfactory condition. It shall be installed in such a manner that the operation of the equipment, should this be required to function, is in no way hampered. The Contractor shall be held liable for any damage caused by them, their employees and subcontractors (if any) in carrying out this Contract. ENVIRONMENTAL PROTECTION The Contractor shall take all necessary steps to protect the environment. Dispose of all rubbish from site, take all possible precautions to minimise the nuisance of dust and noise. The University has an active recycling program for disposal of used materials. The Contractor shall ensure that all materials on site are secured in the event of storms and high winds. The Contractor shall at all times maintain a safe working environment. The Contractor shall at all times ensure the waterproof integrity of the buildings is retained. Rectification of damage to buildings and contents caused by water inundation or construction work is the responsibility of the Contractor. COMMISSIONING The contractor shall test all associated hardware prior to the Pre connection documentation being submitted to the ANU Security Project coordinator. It should also be noted that typically 4 to 8 weeks are required for system programming subject to the project scale, this period has to occur before commissioning acceptance tests can be conducted by ANU Security. The installation contractor shall test and commission all hardware programming including, door access, door open too long, fire trips, door forced, door not locked, readers, inputs, outputs, tampers, controllers, request to exit buttons and break glass units with the ANU maintenance contractor [reference RFT Attachment J] All tests are to be full functional tests of the system through to the ANU Security Control room. 43

9.2 9.2.1

9.2.2

9.2.3

9.3 9.3.1

9.4 9.4.1

9.4.2

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 9.4.3 The contractor shall perform acceptance tests with a project representative from ANU Security. This will include documented inspections of the installation to ensure workmanship and quality is to the ANU specification. Random testing but not limited to, readers, break glass units, tampers, mains fail alarms and door open too long alarms will be carried out with the project coordinator, ANU Security and the contractor. Note: The University will require clauses 9.4.1 through 9.4.4 to be satisfied prior to agreeing to practical completion for the access control phase of the project. Any defects will be identified to the Project Coordinator for rectification. On acceptance the ANU Security representative will sign the commissioning documentation provided by the contractor. DEFECTS LIABILITY A minimum defects liability period of 24 months from the date of acceptance by the project manager on behalf of the University. The warranty for this period shall include any pre - existing works, cabling or installations incorporated into the package of works identified as the University access control system and which forms a component of the operating system under this tender and contract. In the compliance statement on warranty, tenderers shall clearly describe how the warranty provisions shall be met and what reliance if any exists by the tenderer on support from other suppliers of components of the tendered systems. OPERATION AND MAINTENANCE MANUALS As Installed Maintenance and Installation Manuals shall be supplied by the Contractor. A draft copy must be submitted to and for approval/comment by the ANU Facilities & Services Department three weeks prior to completion of each precinct commissioning phase for Stages 1 and 2 of the RFT. The Manuals shall include installed drawings Drawings shall include all hardware, Power supply, Batteries, and network point locations. They will also show ALL cable routes. The Manual shall also include all cable and termination schedules. The Manuals shall also show all system program settings including, Programming of all time clock settings, day files, alarm points, zones and alarm zone descriptions and PPAR messages. Pre Connection documentation. Commissioning documentation. Service contacts including after Hours Maintenance works proposed during defects liability period. TRAINING & PASSWORDS 44

9.4.4

9.4.5

9.4.6

9.5 9.5.1

9.5.2

9.6 9.6.1 9.6.2

9.6.3 9.6.4 9.6.5 9.6.6

9.6.7 9.6.8 9.6.9 9.6.10 10.

ANU SECURITY ACCESS CONTROL SPECIFICATION 2-2010 10.1 10.1.1 10.1.2 SYSTEM ADMINISTRATION The University fully expects that it will be able to manage, maintain, alter and administer the database information it enters into the system. Tenderers will provide full details (including costs if any) to provide the appropriate training to ANU security administration staff to accomplish Clause 10.1.1. Tenderers shall confirm they will provide all software system and hardware passwords and access codes/dongles etc required to undertake Clause 10.1.1 and also confirm there are no restrictions on the University rebuilding the software systems on University servers or client terminals as required by the University. SOFTWARE LICENSING PROJECT INSTALLATION AND MAINTENANCE: Tenderers shall provide pricing information that will allow identification of the following; (a) (b) (c) All licensing costs (by component or feature set as applicable item) included in the tender $ All licensing and software maintenance costs included in the warranty period (2yrs) $ A full schedule of software licensing and maintenance costs for the ongoing maintenance period after warranty expiration. The schedule shall also identify what new releases and updates are covered by the license schedule. The schedule shall have a validity period of not less than 3 years from the expiration warranty. Tenderers who do not have a licensing regime in place as part of their bid pricing shall confirm that no software license/maintenance fee will be applicable for a period of at least five (5) years from project completion and acceptance by the University.

10.1.3

10.2 10.2.1

10.2.2

Any software licensing schedule supplied shall allow the University to simply identify the component costs of any license or software maintenance fee. Tenderers should identify any alternative pricing structure to license fees, including fees paid to third party software suppliers encompassed by this tender, that they may consider of benefit to the University.

10.2.3

SHOULD ANY QUESTION ARISE FROM THIS SPECIFICATION PLEASE CONTACT THE ANU SECURITY MANAGER FOR CLARIFICATION.

45