Access Control (card access)

Transcription

1 Access Control (card access) This page should be read in conjunction with security systems - general requirements. Aesthetic Cabling Unless cabling is to be in purpose built conduits within walling, which shall be a project specification on new build or refurbishment projects, all other cabling shall be surface mounted in trunking that is commensurate and sympathetic with the surrounds and the environment in which it is to be installed and to prevent tampering. No bare cables are to be installed. Performance objectives To provide security and controlled access to buildings and individual areas within buildings, by means of a card access system. Standards All items to be designed and installed to relevant standards, and in accordance with BS EN Readers are to be mounted so as to be DDA Compliant. Compatibility All card access equipment to be installed, particularly readers, interfaces, locks, controllers and communications equipment, must be fully technically and functionally compatible with the University s central access control system. This system is based upon the TBC access control application as produced by TBC, the TBC application is fully MS SQL and Oracle compatible and will reside on a central server. It is accessed from specific points around the University, using the connectivity provided by the University campus IT network and by locally installed TBC software. This connectivity will be by standard IP protocols over the network, and will utilise a Cat 5 infrastructure as a minimum standard, connecting via TBC hubs and routers at specific locations throughout the University. This provision is a University responsibility unless stated otherwise.

2 Installing companies will be expected to provide, install, test and commission access control components from, and including, controllers down to, and including, all door access control components (i.e. controllers, cabling (normally RS485), containment/ducting, readers, locks, monitor points, emergency egress etc), ensuring that the same are fully compatible with the TBC system and its components, and the network infrastructure. The TBC is installed and maintained by TBC. The card access network is a distributed configuration, based upon one or more controllers in each building or complex, such controllers utilising the communications methodology described above. From each controller, one or more readers are hard-wired, the actual number of readers being dictated by the type of controller in use (generally, up to 16 readers are acceptable) or where specified differently. Additional offline and wireless contactless readers manufactured by TBC can be fitted in lower-risk areas where access control is required. Components requirements - General system compatibility parameters Cardholder details Each cardholder record consists of a number of fields of personal information with each field including a definable title. Both cardholder records and the history log will be capable of using any one of these fields of additional information or their title as a parameter to sort by, and to search on for reporting/management information purposes. System occurrence reporting The time and date along with information relating to the current quantity, priority and status of any alarms will be sent to the central system. All readers, alarm monitoring points, and switching outputs activity will also be transmitted to the security control room, where it will be associated with a custom text description of their location, which will be utilised as the operator s reference when selecting devices within any particular function. Individual readers or group of readers can be assigned to a time code, which will define the access times/activities for the selected doors, access being denied for those readers not selected. Controllers All controllers are to be those within the TBC range of such items; controllers will be identified by type at the project definition stage, with the resultant specification of type being identified at that stage and in accordance with perceived hardware configuration per building or door. Thus the

3 number and type of TBC controllers will depend upon the stated need. This may include the provision of controllers to facilitate biometric readers. Any TBC compatible controllers must nevertheless be capable of the following functions as a standard: 1. When operated off-line the ability to perform normal access decisions, including if a cardholder is valid at that door and at that time, along with PIN or biometric validation where installed, is a requirement. All transactions will be time and date stamped by the controller at the time they occur, with this information being the reference used by the central system s history log. Controller clocks will be periodically synchronised with this central system; pre-scheduled and conditional commands shall be capable of being executed locally thereby preserving operation when offline. 2. Controllers must be capable or near real-time updating from/to the central server, which will include data changes/additions/deletions, card holder access parameters, controller/reader operational modifications etc. Controllers must also be capable of storing alarm or event data for onward transmission to the central system history log, and must also be capable of immediate response to on-line demands for such data/information. In the event of the remote site detecting an access or monitored alarm it shall immediately initiate a contact call to the central system and present this to the operator for action. 3. When operating offline i.e. normally in the event of a communications loss, all activity shall be capable of being stored within the controller s local memory. Each controller shall support a means of apportioning the amount of memory available for cards against the required offline local storage needs for transactions and alarms. Controllers where the maximum card memory has been utilised shall be capable of learning new cards, by removing cards, which least frequently uses that controller s doors, and then advising the central server of the same; currently, the capacity for 30,000 cards is a minimum requirement. Mains power by un-switched and fused (13 Amp) spurs for each controller or set of controllers shall be provided. In addition, each controller must have an integral back-up battery power supply of at least one 12 volt, 7-9Ah, valve regulated, sealed lead-acid and rechargeable battery, designed to provide a minimum of four hours back-up under normal use. The local controller shall be able to detect and report the following conditions: Valid access request, Lost card, Wrong time, Wrong door, Invalid card, Unknown card, Inactive card, Card Watch, Anti Pass back,, Wrong PIN/biometric and Duress Entry. Controllers shall fully monitor and control access point doors with individually configurable, standard and extended, time periods for lock release, door open, and a local door pre-held warning sounder. The pre-held warning period shall cause a local audible indication to be provided at the reader to indicate that the door has not been closed.

4 Alarms originated by the controller and subsequently presented to the operator at the central control for action shall include door forced, door held open too long, emergency break glass operation and reader tamper conditions. The option to suppress reporting of such alarms during office hours on a timed basis is a requirement. Each door shall also include a voltage free relay output to provide an output signal to the controller from the point of the door being released until the door re-closes. In the event of corruption of a controller s local database then it shall be able to detect this condition and automatically request the relevant data to be downloaded from its local server. This action should not require operator intervention. Card readers Controllers shall be capable of interfacing with a range of reader technologies including proximity, TBC wire contact-less smart chip cards and for some low security areas, code only operation; biometric readers (fingerprint) will also be required in some locations. Unless determined after consultation with Security Services, all doors should have card readers fitted to both sides of the door to control access and egress. The University currently utilises the TBC proximity contactless smart cards to ISO/IEC Type A standard with 48 bit authentication keys, at 13.56Mhz read/write. Readers are therefore to be fully compatible with both this technology and the ISO standard. All readers are to be both weatherproof and temperature tolerant between the range 5ºC and +40ºC, and will require 12v DC with an average power consumption of 75mA. Current readers deployed are manufactured by TBC Door locking mechanisms Electronic magnetic locks (maglocks) are to be used on card access controlled doors; these shall be mounted at the top of the door. They can be either of 500, 850 or 1200 Ibs force as required, with Z and L brackets, externally fitted, as required and specified. Green emergency break glass units shall be provided internally at each door, so that power to the maglocks can be disengaged to allow emergency egress, such break glass units shall be monitored (as monitor points for alarm initial) on the access control system. Door locking mechanisms shall be able to operate in a door control configuration of proximity smart card without PIN for both entry and egress and with biometrics (fingerprint) and PIN validation where required. In addition, where card access locking is to be provided on DDA doors, then full liaison is to occur at specification stage to determine the appropriate technical linkage to ensure that the automated

5 locking/opening mechanisms either respond to, or are linked to, the card access controller to ensure that both inter-operate effectively and efficiently and without incompatibilities, especially in regard to timed operation. Entry barriers systems In high-risk buildings or as designated, entry barrier systems will be fitted to prevent tailgating. Such systems will work in conjunction with the specified access control system. The current system utilised by the University is a TBC or TBC. An additional manufacturer is TBC. A full design and consultation exercise must take place before any such system selection takes place. System approval All specifications for access control systems are initially to be approved by the Head of Security or deputy before subsequently being authorised by the Project or Surveyors Offices of the Capital Maintenance and Infrastructure department of the University of Bath. System connection The contractor shall connect any intruder detection systems in concert with Estates Operations departments and Security Services staff of the University, via TBC connectivity, to the BOLD Communications equipment located within Security Control Room, using normal telephony technology via the University s internal telephone system, which is a dispersed configuration utilising TBC technology. Systems should be capable of being connected via IP to the TBC where available for subsequent display on a graphical user interface (GUI) Liaison with UoB staff The contractor shall provide professional and expert advice and guidance to University staff on the installation and warranty maintenance of all such systems, together with relevant costing, quotations etc., for approval prior to any change, modification, enhancement or new installation. All such works and/or provisions to be in full accordance with NSI (previously NACOSS) standards except where specifically agreed otherwise in writing by the Head of Security or deputy. Lifecycle Installed hardware should be capable of operating in continuous use for a minimum of five years. Approved manufacturers Card Readers TBC Controllers - TBC

6 Entrance barriers TBC Spares TBC.