*********************************************************************************************************

Transcription

1 13860 ACCESS CONTROL SYSTEM (ACS) ********************************************************************************************************* SPECIFIER: CSI MasterFormat 2004 number: ********************************************************************************************************* PART 1 GENERAL 1.1 SUMMARY A. Provide a complete, operable and tested Access Control System (ACS), including but not limited to all necessary wiring, controls, accessories, hardware and software. 1.2 RELATED REQUIREMENTS A. Coordinate access control system (ACS) with work before and after. See especially: 1. Electric lock strikes and door hinges wired to ACS. Section Electrical raceways (including conduits and cable trays), Division 16 junction boxes and power cabling sufficient to support both current and specified future ACS configurations. B. The following work does NOT integrate with the ACS under the work of this section: 1. Intrusion detection system. Section Security camera system. by MDCPS 1.3 DEFINITIONS A. Definitions of Parties: 1. ACS manufacturer/installer: The Contractor s subcontractor that performs and integrates design, access control products, software, installation and configuring of the ACS work, that provides instruction, that is available to repair and add to the ACS, and that is a dependable source of spare parts for 10 years. 2. CTF-SCS: M-DCPS Facilities Operations Maintenance Capital Task Force Security Camera Systems Department. 3. RMC: M-DCPS Region Maintenance Centers. 4. DCOM: M-DCPS District Communications Operations Management center and staff. 5. ITS: M-DCPS Information Technology Systems Department. 6. Client: M-DCPS. 7. Authorized: Authorized by M-DCPS or a M-DCPS-appointed ACS administrator. 8. ACS administrator: A person authorized by M-DCPS to delegate ACS access, programming, response, and other typical ACS operations and to oversee those employees so delegated. 9. ACS operator: An M-DCPS employee who is authorized by the ACS administrator to access the ACS and to perform authorized actions. 10. Cardholder: A person credentialed to enter a facility at authorized times by card. 11. Visitor: Any person not an administrator, operator or cardholder, who may be temporarily credentialed to enter a facility. Project No. SPECIFICATIONS GUIDELINES

2 B. Definitions for Software and Equipment. 1. CSA: Client software application. 2. CUI: Configuration user interface. 3. SUI: Surveillance user interface. 4. IO: Input / output. 5. PC: A computer that is part of the ACS. 6. REX: Request to exit. 7. SDK: Software development kit. 8. SSM: Server software modules. 9. UCT: Coordinated Universal Time (as sent to satellite by NIST and USNO) 1.4 SYSTEM PERFORMANCE A. ACS shall provide a complete, operable, and integrated system that shall include but not be limited to the following items: 1. All equipment, editable software program, cabling, and configuring as needed for facility security at all points of access. 2. ACS shall identify and authorize (or deny) the entry and exit of persons and groups using proximity card readers, expandable to add or substitute other credentialing, controlling and reporting technology in the future. 3. ACS shall communicate, trigger alarms, and report the status of doors and persons in the facility at all times to facility administrators and DCOM, as needed for the security of occupants and property. 4. ACS shall enable administrators to temporarily or permanently credential persons and groups for entry, and to produce cards. 5. ACS shall link with door hardware, UCT time signals, and phones in the facility, with provision for possible future linking to detection or alarm systems, some of which may follow IP protocol. 6. The ACS manufacturer/installer shall configure, test and demonstrate the system until every point of access in the facility is secure. 1.5 QUALITY ASSURANCE A. ACS manufacturer/installer: A firm with at least 10 years documented experience in providing access control systems of the type specified herein. The manufacturer/installer shall: 1. Integrate all the work defined above during system design, its execution, and for the duration of the specified special warranty. 2. Employ a supervisor, foremen, and key mechanics who each have at least 5 years of documented ACS design, and installation, callback and maintenance experience in the ACS industry. 3. Employ technicians and engineers who have been trained and certified on the ACS software and associated interfaces by the ACS manufacturer. 4. Provide proof of certifications for each of these persons before start of installation. 5. Inform provider of electrical raceways of location and extent of raceway needs to serve ACS equipment. 6. Use factory-trained technicians in making all electrical connections. 7. With the Contractor, be responsible for the functioning of the ACS, free of defects. Project No. SPECIFICATIONS GUIDELINES

3 B. Manufacturer / Installer Resources and Response: The Contractor and ACS manufacturer/installer shall provide proof that the ACS manufacturer has a local ACS installer with manufacturer-authorized certifications and access to all local manufacturerauthorized product distributors who collectively carry a complete inventory of each manufacturer s ACS products, and who will respond with mechanics and equipment to calls from the M-DCPS or the facility s administrator. 1. Location of local ACS manufacturer/installer: Miami-Dade County or no more than 60 miles away from facility. 2. Response Time: Manufacturer/Installer shall send qualified mechanics to the facility, after notification by or phone: a. Within 4 hours of notification of emergencies. b. Within 2 weekdays of notification for non-emergency calls or maintenance 1.6 SUBMITTALS A. Access Control Schedule, as specified in PART 3, prepared by Contractor s ACS provider/installer in consultation with CTF-SCS, and A/E. B. Scope and Procedure: Submit 4 copies of 1. List, for A/E and M-DCPS approval, 3 similar projects (with owner contact information), installed and maintained by proposed system integrator. 2. List, with brief descriptions, of security equipment and software features that will be supplied, following the requirements of PART 2 below. 3. Product data sheets, riser and connection diagrams specific to this Work. 4. Proposed acceptance test procedure. 5. One copy of each of the above shall be for review C. Electrical Infrastructure Quantities, for provision by Contractor: ACS manufacturer/installer shall submit the needed quantities and extent of the following, directly to Contractor (without review or approval by A/E): 1. Electrical boxes and power cabling as needed for ACS. 2. Empty conduit scheduled by ACS manufacturer/installer to serve doors not currently shown in the Construction Documents to receive electrical access control devices in the future. D. Shop Drawings: Submit 10 copies of: 1. Riser and connection diagrams, schedules for location and function of each device, and specification data sheets for this Work. Do not submit generic riser diagrams. E. Record Documents: After substantial completion of the ACS, submit 4 paper copies and 1 electronic copy that includes: 1. Detailed record drawings. Include floor plans of the facility showing Access Control Rack, Client Station, and controller locations as well as each point of access, type of access control, settings as configured, and level of security all in editable form suitable for updating and extending by M-DCPS and the facility. 2. Floor plans. Based on the Contractor s final record document drawings for the Work. Project No. SPECIFICATIONS GUIDELINES

4 3. O&M manuals. With the 4 paper copies, submit 1 set of operation instructions and manuals and the instruction documents used in training the M-DCPS operating staff. 4. Serial numbers. Provider/installer s part and serial numbers for each item of installed and specified equipment for M-DCPS Property Control Auditing. 5. Warranties. Executed special warranties. F. Additional Deliverables: to be delivered directly to CTF-SCS after M-DCPS s acceptance of record documents: Keys, spare parts, and special tools, plus 1 set of detailed record drawings, floor plans, and O&M manuals as specified above. 1.7 SPECIAL WARRANTIES A. Product Special Warranty 1. Duration: Provide a 3-year limited warranty from the ACS manufacturer/installer that covers items of ACS software, equipment, cables and cards, starting when the system is considered substantially complete by the A/E and M-DCPS. 2. Scope: Warrant against defects in software, equipment, cables, and cards. a. Warrant that all items of equipment are new and not used. b. Replace access cards in cases of deterioration with age or damage due to reasonable flexing. 3. Format of special warranty: Provide on letterheads of ACS component manufacturers or on letterhead of producer/installer, incorporating as a minimum the special warranty terms specified herein, and signed by corporate officers. 4. Remedy: Whenever equipment defects appear within the specified special warranty period, provide replacement components, or repair components to new condition, along with replacement/repair labor at no cost to M-DCPS and with no pro-rata charge for equipment depreciation. B. Installation Special Warranty: 1. Duration: Provide a 5-year limited warranty from the ACS manufacturer/installer that covers the installation and functioning of the product, starting when the system is considered substantially complete by the A/E and M-DCPS. 2. Scope: Warrant against defects in cabling, quality of installation, connections to hardware and sensors, programming, configuring and subsequent functioning to meet the needs of the facility. 3. Format of special warranty: Provide on manufacturer/installer s letterhead, incorporating as a minimum the special warranty terms specified herein, and signed by corporate officers. 4. Remedy: Whenever defects of installation and function appear within the specified special warranty period, provide the labor, tools, repair materials and minor parts (not items of original equipment) to diagnose and repair the ACS at no cost to M-DCPS. 5. Response: Respond to emergency calls and routine calls within the times and with the resources specified in Quality Assurance. Project No. SPECIFICATIONS GUIDELINES

5 PART 2 PRODUCTS 2.1 ACCESS CONTROL SYSTEM (ACS) A. ACS shall consist of command centers (Access Control Center and Client Station), microprocessor-based servers and controllers, I/O boards, proximity card reading devices, and cabling, operating on the specified software, and all backed by one or more dedicated UPS. 2.2 ACS SOFTWARE A. Overall Software and Equipment Design: 1. The system software is comprised of the following Software Modules, Applications and Utilities, each of which has several components, as specified in the specification articles that follow: a. Server Software Modules (SSM) b. Client Software Modules (CSM) c. Client Software Applications (CSA) d. Client Management Applications (CMA) e. Software Utilities. 2. ACS shall be an Enterprise class client/server access control software solution, capable of performing and integrating multiple security functions such as the reconfiguring, managing and monitoring of cardholder access, hardware units (controllers), events, alarms, visitors, as well as real-time tracking and reporting. 3. Base ACS on an open-architecture client/server model, highly scalable, providing for future growth, backward compatibility, and designed to support and interface with multiple ACS hardware manufacturers and other 3rd party equipment and applications as selected by M-DCPS. 4. Make the ACS compatible with existing IP systems and with ACS already in facility. 5. Base communication between the SSM, CSA and other components and the hardware controllers on TCP/IP protocol. 6. Design ACS to operate in a multi-user and a multi-tasking environment. 7. Design ACS to support: a. Firmware updates that provide the system with all additional updates and integrations. b. Installing all SSM, CSA, and other components on the same machine. c. Conversely, also support a distributed environment where SSM, CSA, other components can be installed across several PC s over an IP network. d. The creation of security partitions. Security partitions shall allow the system administrator to segment the configuration database and to group multiple entities within a security partition. e. Identify doors that may or will be put under access control at a date later than the configuring of the ACS under this contract. 8. Protect ACS against database server failure using standard off-the-shelf solutions, including UPS. ACS shall preserve all of its data in spite of power interruption. B. ACS Design Features. Design, produce and install the ACS to: Project No. SPECIFICATIONS GUIDELINES

6 1. Follow standard MDCPS network configurations for security systems by Information Technology Services Department (ITS) and by CTF-SCS. 2. Run on a standard PC-based platform, using the latest and most advanced design tools. 3. Interface easily, minimizing the number of external applications needed to configure and monitor the system. User interface shall consist of a single configuration client interface and a single live monitoring client interface. 4. Be compatible with multiple 32-bit operating systems. The ACS client and server modules shall run on Windows XP Professional with Service Pack 3 or Windows Server 2003 with Service Pack Build ACS database server(s) on Microsoft s SQL Server 2005, including SQL 2005 Express Edition. 6. Produce messages to users at all levels, including visitors, in plain English, free of jargon and with minimal use of abbreviations. Do not use terms that need definition for users. Do not employ mnemonic-type or transaction code-type messages. 7. Protect the ACS with passwords and encryption as specified below. C. ACS Scalability and Capacity: 1. Design the ACS to support a wide range of configurations. The ACS shall be capable of supporting small access control configurations that consist of a single door and one reader. The ACS shall also be highly scalable to support configurations consisting of a multitude of doors with facilities spanning multiple geographic areas. 2. ACS shall be upgradeable - one entity at a time - for example: 1 credential at a time, 1 door at a time, 1 cardholder at a time, etc. 3. ACS shall support an unlimited number of Access Server Modules. Each Access Server Module shall support several hundred hardware controllers. 4. ACS shall permit multiple instances of Client Software Applications (CSA) to run simultaneously on the network. 5. ACS shall support a large number of logs and historical transactions (events and alarms), with that number limited only by the amount of hard drive space available. D. ACS Encryption and Security: 1. Design communication between the SSM and CSA (sever-to-server and client-toserver) for encryption. The encryption method shall use a 128-bit AES encryption algorithm (at a minimum). 2. Communication between the SSM and hardware controllers shall be encrypted if supported by the hardware controllers. 3. Protect the ACS with passwords at each level of administration (such as DCOM, CTF-SCS, and levels within each facility). Password-protect each ACS client software application (CSA). 4. Encrypt and store passwords in the Configuration Server database. 5. The ACS shall limit what users can view in the Configuration Server database via security partitions (database segments). The site administrator, who has all rights and privileges, shall be allowed to segment a database into multiple security partitions. An operator who is given access to a specific partition shall only be able to view entities (components) within the partition that he has been assigned to use. 6. ACS, and each of its components, shall retain all information after power interruption, without time limit. The UPS switchover time interval shall allow no information loss. Project No. SPECIFICATIONS GUIDELINES

7 E. ACS Operation Modes. Design ACS to support 3 modes of operation: 1. Online mode. Online, the ACS software shall make all access decisions in real-time. Requests from the hardware controllers and responses from the Access Server shall be sent over the network. This shall be supported only with controllers that are capable of functioning in the online mode of operation. 2. Mixed mode. In mixed mode, the hardware controller shall make all access decisions and dynamically report activity to ACS in real-time. 3. Offline mode. Offline, the hardware controllers shall function as stand-alone units. ACS shall revert to the offline mode when the hardware controller is unable to communicate with ACS. Offline, the controllers shall manage the following: a. All access requests. b. Keep a log of access activity. c. Base access decisions on information stored in the controller. d. Upload activity logs to ACS when communication is restored. 2.3 SERVER SOFTWARE MODULES (SSM) A. Description of SSM: 1. SSM shall consist of a Configuration Server, Access Server Modules, and a Server Monitoring Service and shall automatically launch at computer startup whether or not an administrator or operator is logged on. 2. Configuration Server shall support all Access Server Modules, which receives, process and respond to requests from the CSA. 3. Server Monitoring Service shall continuously monitor the state of all SSM services. B. Configuration Server: 1. The Configuration Server shall be the central database that contains all the system information and configures the system s components. 2. The Configuration Server shall support the present and future configuration and management of the Access Server Module functions listed below: a. At system startup, the Configuration Server shall download all the configuration information to each Access Server Module under its control. b. Configuration Server shall authenticate users and give access to the ACS based on predefined access rights or privileges for each user level. c. Configuration Server shall continuously monitor the following: 1) Server application connections. 2) Client application connections. 3) Controller connections. C. Provide Access Server Modules configured now and for the future for the functions specified in CLIENT MANAGEMENT APPLICATIONS (CMA) below. D. Server Monitoring Service (SMS): Project No. SPECIFICATIONS GUIDELINES

8 1. SMS shall continuously monitor the state of all SSM services. SMS shall automatically launch at system startup, whether or not an administrator or operator is logged into his account. 2. If there is a malfunction or failure, SMS shall restart the failed service. As a last resort, SMS shall reboot the PC if it is unable to restart the service. SMS shall also be able to manually start and/or stop one or more of the SSMs. 3. SMS user interface shall be accessible from the system tray. This interface shall provide the administrator or operator with the following: a. A real-time list of SSMs running on a PC. b. The status of the SSM (STARTED or STOPPED). c. A log of status-related events and associated timestamps. d. A Telnet console to log onto an SSM. 2.4 CLIENT SOFTWARE MODULES (CSM) A. CSM Functions. 1. CSM shall provide the operator interface for ACS configuration and monitoring. 2. CSM shall consist of: a. The Configuration User Interface (CUI) for system configuration. The Server Administrator shall be used to configure the server databases; b. The Surveillance User Interface (SUI) for surveillance; c. The Web Client; d. The Server Administrator. 3. The CSM shall be: a. Windows based. b. Written in plain English, jargon-free, with minimal abbreviating. c. Provide an easy-to-use graphical user interface (GUI). 4. CSM shall perform functions specified for the SUI without interfering with any of the SSM operations, such as responding to access requests and logging ACS events. 5. CSM shall support multiple forms of network connectivity, including LAN, WAN, VPN, and Internet technologies. Each component of the CSM shall be able to log into the ACS from a remote site. 6. All CSM applications shall have an authentication mechanism by which administrators can check operator authorizations and define specific access rights and privileges for each operator. B. Configuration User Interface (CUI). Provide or enable: 1. The system administrator to change the configuration of system and each application. 2. Decentralized configuration and administration of the entire ACS and each application from anywhere on the IP network. 3. The system administrator to configure each ACS application. An application is defined as a system component used to create an access control system. 4. Status information to authorized operators. 5. Easy navigation throughout CUI. Project No. SPECIFICATIONS GUIDELINES

9 6. Easy navigation between this application and each other CSA application for authorized operators by single point and click function. 7. Facilitate the creation of application entities by use of installation wizards that guide the administrator or operator through a step by step installation process. 8. Include a Troubleshooter utility to help an administrator to generate reports on cardholders and access points. 9. Provide a static reporting interface to: a. View historical events based on entity activity. b. Operator shall be able to perform actions such as printing a report and troubleshooting a specific access event from the reporting view. c. View audit trails that show a history of operator / administrator changes to an entity. 10. CUI shall include an integrated import utility. C. Surveillance User Interface (SUI). Provide or enable: 1. A graphical operator interface to control and monitor the ACS, consisting of a single monitoring interface for video and access control events and alarms. 2. Decentralized monitoring of the entire system from anywhere on the IP network. 3. An interface to support multiple functions. 4. Operator to monitor the activity of the various entities in real-time. 5. Operator to customize to user preferences. 6. Operator to receive status information. 7. Display several visual cues when the system status has changed. 8. Let operator view and acknowledge alarms listed in the alarm layout. Operator shall be able to acknowledge multiple alarms at one time. 9. Support multiple displays of tiled information. Support a range of tile displays from 1 tile (1x1 matrix) up to 9 tiles (3x3 matrix). 10. Let operator remotely unlock a door using icons on the display tiles or icons on the alarm / event list. 11. Let operator remotely override a door s unlocking schedules and their exceptions by clicking on an icon among the display tiles. Operator shall define override period from the SUI. 12. Provide an interface to manipulate playback video (play, pause, stop, rewind, fast forward, record), with video surveillance integration. 13. Provide the option to filter which events shall be displayed in the display tile layout and/or event list layout. D. Web Client. Provide a search and modifying feature that: 1. Allows administrators and operators to perform configuring, managing and reporting activities using Microsoft Internet Explorer. 2. Is a truly thin client, not requiring the download of any ACS-specific files or executables on the ACS workstation. 3. Configures and manages cardholders, cardholder groups, credentials and access rules. E. Server Administrator. Server Administrator shall: Project No. SPECIFICATIONS GUIDELINES

10 1. Be used to configure all servers (for the Server Software Modules, Client Software Modules, Client Software Applications, Client Management Applications, and Software Utilities), associated licenses, and the services available on each local PC. 2. Be accessible through a graphical user interface (GUI) and shall be installed on all PCs that run one or more SSM. 3. Enable the administrator to perform the following functions: a. Configure the databases and database servers. b. Start/Stop a database server. c. Define the client-to-server communications security settings. d. Configure the network communications hardware, including connection addresses and ports. e. Add and configure hardware extensions and discovery options. f. Configure system SMTP settings (mail server and port). g. Configure the Server Monitoring Service automatic settings. h. Configure event and alarm history storage options. i. Manually back up databases and/or restore the server databases. j. Configure options for Telnet access to the SSM. ************************************************************************************************************ SPECIFIER: With the MDCPS Project Manager, develop the scope of CSAs, as stated in the Design Standards for this Project, selecting from the choices and listing of functions and applications that follow, and adding the special needs of this Project. Obtain approval of MDCPS Facilities Operations Maintenance and edit the following text accordingly. ************************************************************************************************************ 2.5 CSA (CLIENT SOFTWARE APPLICATION) FUNCTIONS A. Integration of ACS with Video Surveillance System. Enable: 1. Operators to view live and recorded video. 2. Operators to enable / disable the video surveillance integration feature. 3. Connecting ACS to multiple external video systems (a federation-type capability). 4. Viewing one or more video streams tied to such entities as standalone cameras, doors, areas, or elevators. B. System Settings Management. Enable: 1. Configuring and managing of general system settings. Operators shall be able to add, delete, or modify system settings. 2. Viewing and/or configuration of the following properties for the ACS: a. License information (System ID, expiration date, supported options and features, package name). b. Current applications and operators that are online. c. Entity expiration warnings. d. Custom events. e. Custom fields. f. Video surveillance settings. 3. Operators to set discovery settings such as the controller type and discovery port. 4. Manual unlocking of locks. Project No. SPECIFICATIONS GUIDELINES

11 C. Controller and IO Unit Management. Enable: 1. Discovery, configuring, and managing of controllers and IO modules (hardware units). 2. Operators to add, delete, or modify a controller. 3. The configuring of units from the CUI. 4. Automatic IO unit discovery. Enable operators to set the PC for discovery ports and types of unit discovery. ACS shall automatically detect all connected devices. 5. Remote firmware upgrades, if supported by the hardware. Execute upgrades on edge devices connected to the network. 6. Use of multiple reader types, including card or keypad readers, with ability to define controller settings on a controller-by-controller basis, permitting full customization of the access control infrastructure by customizing controller settings based on card and reader specifications. 7. Inputs detected by the controller or IO modules to trigger events in the ACS. 8. IO module inputs and outputs that support both operator-defined and physical names, with ability to modify operator-defined names. 9. ACS to send grant-or-deny access commands to the controller (online mode) as supported by the hardware controllers. Base commands to lock / unlock a door on a request from a cardholder or on an unlocking schedule (or an exception to it). 10. Maintenance mode to: a. Go to maintenance mode operation during controller installation or maintenance. b. Unlock a door (overriding lock schedules) while in maintenance mode. 11. Unit swap utility to: a. Support a unit swap utility to swap out an existing controller with a new controller. b. Avoid reprogramming the system whenever a unit is replaced. c. Maintain all logs and events from the old card reader unit. D. User and User Group Management. Enable: 1. Configuring and managing of users (administrators and operators) and user groups. 2. Enable operators to add, delete, modify, or nest authorized users or user groups. 3. User groups are those groups having common access rights and privileges. Each user group member inherits the rights and privileges of the parent user group. E. Cardholder and Cardholder Group Management. Enable: 1. Configuring and managing of cardholders as well as cardholder groups. 2. Authorized operators to add, delete, or modify a cardholder or cardholder group. 3. The viewing and/or configuring of such cardholder properties as first and last names, description (including address, and telephone), extended grant time, status (profile enabled, profile disabled), activation/expiration date, custom fields. 4. Activation/expiration options for a cardholder s profile such as: a. Delayed activation of a cardholder s profile. b. Expiration based on the date of first use of credential. c. Expiration on a operator-defined date. Project No. SPECIFICATIONS GUIDELINES

12 5. Associating a picture with the cardholder s profile. Import the picture from a file, or captured with a digital camera, or captured from a video surveillance camera. When a cardholder event occurs, display the picture of the cardholder in the SUI. 6. Multiple standard picture formats. 7. Creating a cardholder without requiring immediate assignment of a credential, and enabling assignment at a later time. 8. Forming cardholder groups to facilitate mass changes to system settings. 9. Assigning cardholder groups to access rules instead of just one cardholder at a time. F. Credential Management. Enable: 1. Configuring and managing credentials, e.g. access cards and keypad PIN numbers. 2. Operators to add, delete, or modify a credential following the user s privileges. 3. Operators to add custom fields (administrator-defined fields) to credentials. Create new credentials either manually or automatically. 4. Operators to create a credential automatically by presenting a credential to a selected reader. The ACS shall read the card data and associate it to the credential. It shall be possible to automatically enroll any card format (128 bits or less). 5. Operators to manually create a credential by selecting the type of credential and entering the data manually. 6. Operator to create the following credential types (HID Corp. numbers are cited as a standard of quality that must be met by other products): a. HID H10301 Standard 26-bit card format (facility code and card ID) b. HID H bit format (no facility code) c. HID H bit format (facility code and card ID) d. HID H bit format (facility code and card ID) e. HID Corp bit format f. Keypad PIN. 7. Administrators to add additional custom card formats. Custom card formatting shall be flexible as follows: a. Once enrolled, new custom card formats shall appear in the card format lists for manual card enrollment. b. Enable adding any number of additional custom card formats. c. Choosing options such as the following when making a new format: 1) The order in which card fields appear in the user interface or CSA. 2) Whether a field is hidden from, or visible to an operator. 3) Whether a field is read only or modifiable by an operator. 4) Complex parity checking schemes. 5) The order and location of a field s data, allowing changes and additions. 8. Creation of credentials in advance, called unassigned credentials that do not assign the credentials to any cardholders. 9. Creation of multiple credentials for one cardholder, without requiring duplicate cardholder information. Automatically detect and prevent attempts to re-register an already-registered credential. 10. Batch enrolling of credentials. Project No. SPECIFICATIONS GUIDELINES

13 G. Badge Label Designer (templates and production). Enable: 1. The badge label designer function to create badge templates that define the content and format of each badge, and to permit the batch printing of cards. 2. The following badge formats (portrait and landscape): a. CR70 (2.875" x 2.125") b. CR80 (3.37" x 2.125") c. CR90 (3.63" x 2.37") d. CR100 (3.88" x 2.63") 3. Permit the production of custom card sizes and dual-sided badges. 4. A badge template import/export function that allows sharing of badge templates. *********************************************************************************************************** SPECIFIER: With the MDCPS Project Manager, develop CSAs, as stated in the Design Standards for this Project, from the choice of applications that follow, along with special needs of this Project. Obtain approval of MDCPS Facilities Operations Maintenance and edit the following text accordingly. ********************************************************************************************************** 2.6 CMA (CLIENT MANAGEMENT APPLICATIONS) LIST A. List of Client Management Applications. Provide and configure each of the following CMAs (and software utilities) in the ACS software package as part of this Contract. B. Provide and configure as part of this Work: 1. Door management, including: a. IO modules. b. Hardware. c. Door controllers. d. REX devices. e. Readerless doors. 2. Area (and zone) management. 3. Alarm management. 4. Visitor management. 5. Report generation. C. Provide, for configuring at a future date, the following CMAs: 1. Elevator management. 2. IO (input / output) module linking. 3. Schedule management. 4. Access rule management. 5. Event / action management. 6. People counting. 7. Real-time tracking. 8. Reporting and summarizing incidents. 9. Task Scheduling. Project No. SPECIFICATIONS GUIDELINES

14 10. Security partitions. 11. Camera surveillance. 12. Dynamic graphic mapping. 13. Credentials. 14. Access rules. 15. Cardholders and cardholder groups. 16. Users and user groups. 17. Custom output behavior. 18. Custom events and event scheduling. 19. Audit trails (logs). D. Provide, for configuring at a future date, the following SOFTWARE UTILTIES. 1. Import tool. 2. Custom fields (administrator-defined). 3. Software development kit. 2.7 CMA REQUIREMENTS FOR FULL PROVISION AS PART OF THE WORK A. Door Management. Enable 1. Configuring and managing of doors. An operator shall be able to add, delete or modify a door if he has the appropriate privileges. 2. Viewing and/or configuration of door properties. 3. Multiple access rules to be associated to a door. 4. The following forms of authentication: a. Card Only. b. Card or Keypad (PIN). c. Card and Keypad (PIN). 5. Defining schedules that distinguish when CARD ONLY or CARD AND KEYPAD authentication modes are required. 6. Extended grant times: a. Allow setting an extended grant time on a per-door basis (in addition to the standard grant time). b. Allow cardholders the option of using the extended grant time. c. Allow flagged cardholders to be granted access by unlocking the door for the duration of the extended grant time instead of the standard grant time. 7. REX (requests-to-exit). 8. Readerless doors: a. Allow doors configured solely with a lock, a REX, and a door contact, but without readers. b. Allow programming of readerless door using standard access hardware IO modules. External hardware such as timers will not be required. c. Programming unlocking schedules for readerless doors. d. Allow standard door activity reports for readerless doors. Project No. SPECIFICATIONS GUIDELINES

15 9. Associating locking schedules and exceptions to unlocking schedules with specific doors, determining when a door should be automatically unlocked. a. Enable also the use of a specific offline unlocking schedule. b. Use exceptions to unlocking schedules shall to define periods during which unlocking schedules shall not be applied, such as during statutory holidays. B. Area Management. Enable: 1. Operators to add, delete or modify an area or zone. 2. Associating multiple access rules with an area. To simplify assigning of access rules, permit access rules to be applied to areas instead of to doors. Perimeter doors can then be governed by access rules for the area 3. An anti-passback function: When a passback situation (unless exempt or forgiven) is detected, an anti-passback event shall be triggered in the ACS. a. Exempt feature shall exempt designated cardholders from anti-passback rules. b. Operator shall be able to forgive (grant a free pass) an anti-passback violation for a cardholder or cardholder group. 4. Lockdown, and Override: Provide these features with the interlock for areas: a. Lockdown: Use hardware input, such as switch, to prevent all access to an area. b. Override: Allow locking of an area to be overridden and doors to function. c. Include lockdown and override events in area activity reports. 5. Zone management. Also support an authorized operator in adding, deleting, or modifying, configuring and managing zones for input point monitoring. C. Alarm Management. Enable: 1. Creating and modifying an unlimited number of operator-defined alarms. 2. Assigning a time schedule or a coverage period to an alarm. Trigger an alarm only if it is a valid alarm for the current time period. 3. Setting the priority level of an alarm and its reactivation threshold. Support up to 30 alarm priority levels. 4. Defining the period after which the alarm is automatically acknowledged. 5. Defining who receives alarms, routing alarm notifications to one or more recipients. 6. Assigning priority levels that set the order in which persons receive an alarm. 7. Defining the alarm broadcast mode and sending alarm notifications using either a sequential or an all-at-once broadcast mode. 8. Defining whether to display the source of the alarm, one or more entities, or an HTML page. 9. Specifying whether an incident report is mandatory at the time of acknowledgment. 10. Associating an action to an alarm event. 11. Operator shall to add, delete, or modify an alarm if assigned such a privilege. 12. Routing of alarms to specific workstations in the facility by the assigning of alarm recipients. 13. Notifying an address or any device using SMTP protocol. 14. Routing alarms to the SUI for viewing and acknowledgement. Project No. SPECIFICATIONS GUIDELINES

16 15. Allowing creation of alarm-related instructions by displaying one or more operatordefined, interlinked HTML pages following an alarm event. 16. Operators to acknowledge alarms, to create an incident when acknowledging an alarm, and to snooze an alarm. D. Visitor Management. Enable the configuring and managing of visitors by: 1. Enrolling or removing a visitor if he has the appropriate privileges. 2. Supporting check-in and check-out of visitors from the SUI. 3. Permitting cardholder groups to be designated as available for visitors. Enabling operators shall to define access privileges for the cardholder groups (visitor cardholder groups) in advance. E. Report Generation. Enable: 1. The generating of reports (database reporting) accessible through a dedicated layout within the SUI and the CUI, without degradation of system performance. 2. Operators to customize the predefined reports and save them as new report templates, usable to generate reports on a schedule in PDF and Excel formats. 3. Alarm reports to filter information such as alarms, visitors and most reports 4. The following reporting actions: a. Print report to network printer. b. Export report to a PDF file. c. Export report to a Microsoft Excel file. d. Automatically report by schedule and by list of one or more recipients. 2.8 CMA REQUIREMENTS: A. Elevator Management. 1. The managing of elevators. a. An authorized operator shall be able to add, delete or modify elevator access to any elevator. b. Control of access to specific floors, tracking of floor selections, and reporting, using a reader within the elevator car, employing using a controller with an interface to a reader and to multiple output modules with relays. c. Elevator control module to continue to function in offline mode if communication between the ACS and the controller fails. d. Reporting of elevator access events in real time to the ACS. e. Support of one or more cameras in each elevator car. Associate video to elevator ACCESS GRANTED or ACCESS DENIED signals. B. Input / Output (IO) Linking. Enable: 1. Management of all CMA IO functions. 2. Area management that supports IO linking, allowing one or more inputs to trigger one or more outputs. 3. IO linking to be available in offline mode when communication between the server and hardware is not available. Project No. SPECIFICATIONS GUIDELINES

17 C. Schedule Management. Enable: 1. Managing of schedules. 2. An authorized operator shall be able to add, delete or modify a schedule. 3. Full flexibility and granularity in creating a schedule. The operator shall be able to define a schedule in 1-minute or 15-minute increments. 4. Daily schedules to be defined, applicable on a daily basis. Weekly schedules shall define specific schedules for each day of the week. 5. Creation of specific period type schedules that let the operator set schedules for multiple specific days of the year. Starting from the days selected, enable operators shall to define schedules for previous day, current day and day after. 6. Associating schedules with entities such as access rules, door unlocks and exceptions to door unlocks, elevator free access and controlled access, card and PIN obligatory, scheduled tasks, alarms, events/actions and areas (input points). D. Access Rule Management. Enable: 1. Managing of access rules. 2. An operator shall be able to add, delete or modify an access rule if he has the appropriate privileges. 3. An access rule shall be associated to a door side (entry or exit reader), door (both entry and readers), area, or elevator floor. It shall be possible to create an unlimited number of access rules per door, area or elevator floor. 4. Access rules shall determine whether a cardholder or cardholder group shall be granted or denied access based on a schedule. 5. It shall be possible to program an access rule throughout the entire system. 6. An access rule shall be assignable to multiple door controllers. Separate access rules shall not be required if the same rule applies to several independent controllers. E. Event / Action Management. Enable: 1. Managing of events. 2. Operators shall be able to add, delete or modify an action to an event. 3. Receiving all incoming events in the system and take appropriate actions based on operator-defined event/action relationships. 4. Importing of events from multiple video systems. 5. IO linking, in which one or more inputs triggers one or more outputs. 6. Receiving and logging events such as alarm events, application events (clients and servers), area events, camera events, cardholder and credential events, entityabout- to-expire events, door events, elevator events, unit events, system-wide events, anti-passback events, hardware tampering events, 1st-person-in and lastperson-out events, manual station events and request to exit events. 7. Creation of custom events. 8. Executing an action in response to events such as camera bookmarking, presetting and pattern running, sending messages, s and reports, displaying entities to SUI, camera and buzzer commands, triggering alarms and sounds, resetting people counts and forgiving anti-passback violations. 9. A schedule to be associated with an action. F. Real-Time Tracking. Enable: 1. Real-time tracking of entities by a dedicated tracking layout. Project No. SPECIFICATIONS GUIDELINES

18 2. Display of real-time tracking layouts as both real-time activity and historical activity. 3. Independent tracking, in real-time, of such entities as cardholders, cardholder groups, doors, elevators, areas, maps and cameras. G. Incident Reporting and Incident Summarizing. Enable operators to: 1. Create incident reports that report incidents that occurred during a shift. 2. Create standalone incident reports or incident reports tied to alarms, each allowing entities, events and alarms to be added to support the report s conclusions. H. Task Scheduling. Enable: 1. The scheduling of tasks, including recurring or periodic scheduled tasks. 2. Scheduled tasks to be executed on an operator-defined schedule at a specific day and time. 3. Inclusion of all scheduled tasks available within the ACS, such as sending and messages (in ACS or external system), triggering an alarm, output, displaying an entity in the SUI, sounding / silencing a buzzer, running a camera pattern, stating / stopping recording or adding a camera bookmark. I. Custom Fields (Operator-Defined Fields). Enable: 1. ACS to support at least 1000 custom fields, for such uses as: a. Fields for cardholders & cardholder groups, credentials and visitors. b. Fields with text, integers & decimals, dates, images and graphics. c. Creating new custom field types, based on standard fields, supporting operatordefined values from which an operator selects. d. Querying and report generating. e. Grouping and ordering fields following administrator-defined priorities. 2. Operators to define a default value for a custom field. 3. Administrators to define which operators can view and modify specific custom fields, limiting access to this data to specially authorized operators. 2.9 CMA SOFTWARE UTILITIES FOR FUTURE CONFIGURING A. Import Tool. Enable: 1. An integrated import tool to import existing cardholder and credential data. 2. Re-importing a CSV file containing new information that updates existing information in the ACS database, enabling bulk amendments to existing ACS data. 3. Enable manually importing CSV-formatted data exported from a 3rd party database. B. Software Development Kit (SDK). 1. Integrating with external applications and databases using an SD that lets administrators develop new standalone applications or services to link the ACS to 3rd party business systems and applications such as badging systems, human resources management systems (HRMS) and enterprise resource planning (ERP) systems. C. Dynamic Graphical Maps. Enable: Project No. SPECIFICATIONS GUIDELINES

19 1. A mapping function, using digital maps to represent the physical location of such items as cameras, doors, alarms, areas and output groups. 2. The mapping function shall be able to import maps in XAML format. 3. The design dynamic maps using the SDK. Any function available through the SDK shall be available within maps. 4. Various mapping actions using simple and intuitive double-click, right-click or dragand-drop features. Examples of actions available through maps shall include unlocking a door and acknowledging an alarm. D. Audit Trails (Logs). Enable: 1. The generating of audit trails. Audit trails shall consist of logs of operator/administrator changes. 2. Generate audit trails as reports, capable of tracking changes made within specific time periods. Querying of specific operators, changes, affected entities and time periods shall also be possible E. Incident Reports (Logs). Enable: 1. Operators to create reports of incidents that occur during a shift, permitting creation of standalone reports or incident reports tied to alarms. 2. Entities, events and alarms to be added to the report to support its observations and conclusions ACS MANAGEMENT FUNCTIONS A. Overall Management Functions. Enable the following, as a minimum: 1. Add cards to memory after defining where a cardholder can use each card on a doorby-door basis, with defined access times. 2. Modify the access control privileges on individual cards. 3. Group load cards that have the same access control privileges. 4. Delete cards from memory. B. Detailed Management Functions. Enable the following, as a minimum: 1. Define the access system configuration data (such as, which doors are active IN and OUT doors, which have REX alarms, relationship of doors, contact points). 2. Define which doors will report when forced open and the times during the day at which such events will be reported as alarms and reports made. 3. Define a minimum of 3 schedules, unique to each door, with at least 4 access levels for each door controlled by ACS. 4. Define all M-DCPS-recognized holidays. 5. Define pass codes up to 6 levels of operator privileges to modify client software applications. 6. Manually unlock scheduled locks from the Client Station server. 7. Automatically unlock and relock selected locks by time schedule. 8. Obtain hard copy listings of card codes by any combination of privileges. 9. Obtain hard copy listings of the definitions of any door sensor or monitor point. 10. Obtain hard copy reports of the current status of any door sensor or monitor point. 11. Obtain hard copy listings of each report type. Project No. SPECIFICATIONS GUIDELINES

20 12. Select access and monitor point activity messages that are sent to a network printer in the ACS network. 13. Determine if valid access reporting is required only at certain hours of the day and week for selected sensors. 14. Acknowledge alarm conditions. 15. Select which monitor points are to be monitored at all times and which are monitored only during selected periods. 16. Select which doors and monitor points will actuate output contacts. 17. Select which monitor points are to generate an alarm that repeats in a latched mode. 18. Define under what circumstances the system will send a report to DCOM. 19. Define when the system is to report that closing the facility is overdue. 20. Define a 24-character name for each monitor point. 21. Define a 12-character name for each sensor. 22. Define a 12-character name for each employee. 23. Define a 12-character name for each operator. 24. Select card controlled areas that are to be monitored for FORCED and DOOR HELD OPEN alarms, and whether such alarms will be generated at all times or only when system is in NIGHT mode HARDWARE DESCRIPTION A. Minimum System Requirements. 1. Minimum design for Access Control Center server running the SSM and CSA: a. Intel Core 2 Duo 2.4 GHz or better. b. 2 GB of RAM, or more. c. 10/100/1000 Ethernet Network Interface Card. d. 160 GB (minimum) of storage for the operating system, ACS applications and Microsoft. e. SQL Server 2005 Express Edition. f. Standard SVGA video card MANUFACTURER OF ACS SOFTWARE AND HARDWARE A. The access control system, its software and hardware, shall be designed, produced, installed, integrated and configured by one of the following firms, which shall be the source of spare parts and which shall be available to repair and add to the ACS: 1. Continental Access. 2. Hirsch. 3. Kantech. 4. Synergistics. 5. Product of equal function, quality and compatibility as approved by M-DCPS Capital Task Force Department OVERALL ACS HARDWARE CAPABILITIES A. ACS shall interface with hardware access controllers, interface modules and IO modules, whether or not IP-enabled. Project No. SPECIFICATIONS GUIDELINES