SECTION 170001 – SECURITY MANAGEMENT CONTROL …pmabids.com/ashland/17_0001_Security_Management_Control_ Sys… · supplies, conduit, raceways, enclosures, mounting hardware, and

Town of Ashland Town Hall SECTION 170001 – SECURITY MANAGEMENT CONTROL SYSTEM

PMA Architecture 3/14/19 Reissued for Bids 170001 - 1

SECTION 170001 – SECURITY MANAGEMENT CONTROL SYSTEM (SMCS)

1. General

1.1. Introduction - This document includes a general description, functional requirements, characteristics, and criteria for the Security Management Control System (SMCS) for the Ashland Town Hall Building, Ashland, Virginia. The system shall provide an access control system and report alarms and system status information to the Emergency Response Center of the County dial up telephone services. The system provided shall be a complete working system complete with all programming data entry and configuration in accordance with the needs of the County. The SMCS shall include all computer hardware and software; intelligent field advanced processing controller, communication devices, proximity card readers, access cards, I/O boards, power supplies, conduit, raceways, enclosures, mounting hardware, and all other equipment as indicated on the contract drawings and as specified herein, or as required for a complete and operational system to meet the requirements of the building users. All material shall be the manufacturer’s standard catalog products.

1.2. General Description - The required Security Management Control System shall be a multi-function security and access management system. It shall be comprised of one host/server station that will also serve as the only workstation but expandable to one server plus multiple stations simply by adding the client stations and the appropriate licenses to the server unit. A maximum of ten clients shall be possible without having to change server hardware. In the event clients are added in the future, client shall operate in a Client/Server configuration on high-quality IBM compatible Pentium processor personal computers (PC).

1.2.1. The Server (Host) PC, shall have a Pentium 600 1.5GHz or greater central processor. The system shall accommodate a Client (future) shall have a Pentium 400GHz or greater central processor. The exact hardware configurations shall be described in a later section of this specification.

1.2.2. The Security Management Control System shall be designed to grow as project needs grow. The system shall be simple and economical enough to support a single site, yet powerful enough to expand to manage a multi-site network.

1.2.3. The system shall have true multi-tasking and remote terminal capability; independent activities and monitoring can occur simultaneously at different locations. The Operator workstation shall be very easy to use. It shall employ icon based menus and provide a mouse-driven interface for system operation and the creation of color graphic maps.

1.2.4. All objects within the system, i.e., Doors, Readers, Motion Detectors, Door Contacts, Time Intervals, etc., shall be addressed by a unique name. The uses of point numbering or mnemonics shall not be accepted.

1.2.5. Field devices, such as card readers, alarm inputs, control points, etc., shall be connected to fully distributed intelligent field controllers capable of operating without host computer intervention.



1.3. Description of Work - The Security Management Control System shall manage the security operations for a single site or for multiple sites if expanded. Installing the SMCS and bringing it to operational status requires the following major steps:

1.3.1. Coordinate with owner to determine operational requirements and plan system to implement these requirements.

1.3.2. Host Computer will be Room 129.

1.3.3. Install and integrate Access Control, Alarm Monitoring and related security hardware. Electric locking devices (electric strikes or magnetic locks) shall be provided by the door hardware contractor and are to be compatible with frames and door use. Strikes/Magnetic Locks shall be 24VDC, fail-secure (strikes), and continuous duty strikes. Installation shall be by hardware contractor but electrical connections by Security Contractor. Security Contractor shall be licensed by DCJS for Virginia. Installation of complete SMCS shall be by Security Contractor, conduit by electrical contractor.

1.3.4. Configure local access panels and SMCS Server computer system to communicate with one another. Both units will be located in Computer Room.

1.3.5. Enter security system database.

1.3.6. Connect between host system, access controllers, and related hardware.

1.3.7. Test security system communication and operation.

1.3.8. Train operators.

1.3.9. Provide Card Reader technology as indicated on the plans. Cards shall be Proximity type.

1.3.10. Duress Buttons shall be installed under counter/desk at the following rooms (with final locations to be coordinated with the owner in the field): Three at Room 105, integrated into the reception desk, One at Room 216, integrated into the reception desk.

1.3.11. Door Release Push Buttons shall be installed under the counter/desk at the following rooms. Three at Room 105, integrated into the reception desk, One at Room 216, integrated into the reception desk.

1.3.12. Provide Door contacts at all exterior doors: Door Contacts shall be wireless battery-operated DPDT for dual function: Access Management and Security System portion of the application.

1.3.13. Provide Glass Break Detectors as shown on the plans.

1.3.14. Provide 500 Proximity Cards.

1.3.15. Provide equipment and software for proximity card badging and I.D.



1.3.16. Provide dedicated EMT conduit system for all security wiring. All conduit must be concealed within walls and finish systems, terminated in electrical boxes. Home run all conduits from device locations as required for system control wiring to the , Room 114. Provide pull wire in conduits.

1.4. Submittals

1.5. Shop Drawings

1.5.1. Indicate all system device locations which are shown on the architectural plans. No other systems should be indicated.

1.5.2. Indicate all system device locations on architectural floor plans. No other system(s) shall be included on these plans.

1.5.3. Include full schematic wiring information on these drawings for all devices. Wiring information shall include cable type, conductor routings, quantities, and connection details at devices.

1.5.4. Include a complete access control system one-line, block diagram.

1.5.5. Include a statement of the system sequence of operation.

1.6. Product Data

1.6.1. Provide complete product data that includes the following:

1.6.2. Manufacturer’s data for all material and equipment, including terminal devices, local processors, computer equipment, proximity access cards, and any other equipment provided as part of the SMCS.

1.6.3. A system description, including analysis and calculations used in sizing equipment required by the SMCS. Description to show how the equipment shall operate as a system to meet the performance requirements of the SMCS. The following information shall be supplied as a minimum:

1.6.4. Central processor configuration and memory size

1.6.5. Description of site equipment and its configuration

1.6.6. Protocol description

1.6.7. Rigid disk system size and configuration

1.6.8. Backup/archive system size and configuration

1.6.9. Start up operations

1.6.10. System expansion capability and method of implementation

1.6.11. System power requirements and UPS sizing

1.6.12. A description of the operating system and application software.



1.6.13. Contract Close-Out Submittals - Provide three (3) sets of manuals including operating instructions, maintenance recommendations and parts list including wiring and connection diagrams modified to reflect as-built conditions.

1.7. Manuals

1.7.1. Final copies of the manuals shall be delivered within thirty (30) days after completing the installation test. Each manual’s contents shall be identified on the cover. The manual shall include names, addresses, and telephone numbers of each security system integrator installing equipment and systems and the nearest service representatives for each item of equipment for each system. The manuals shall have a table of contents and labeled sections. The final copies delivered after completion of the installation test shall include all modifications made during installation, checkout, and acceptance. The manuals shall contain the following:

1.7.2. Functional Design Manual

1.7.2.1. The functional design manual shall identify the operational requirements for the system and explain the theory of operation, design philosophy, and specific functions. A description of hardware and software functions, interfaces, and requirements shall be included for all system operating modes.

1.7.2.2. Hardware Manual

1.7.2.2.1. The manual shall describe all equipment furnished including:

1.7.2.2.1.1. General description and specifications

1.7.2.2.1.2. Installation and check out procedures

1.7.2.2.1.3. Equipment layout and electrical schematics to the component level

1.7.2.2.1.4. System layout drawings and schematics

1.7.2.2.1.5. Alignment and calibration procedures

1.7.2.2.1.6. Manufacturers repair parts list indicating sources of supply

1.7.2.3. Software Manual

1.7.2.3.1. The software manual shall describe the functions of all software and shall include all other information necessary to enable proper loading, testing, and operation. The manual shall include:

1.7.2.3.2. Definition of terms and functions

1.7.2.3.3. Use of system and applications software

1.7.2.3.4. Initialization, start up, and shut down

1.7.2.3.5. Alarm reports



1.7.2.3.6. Reports generation

1.7.2.3.7. Data base format and data entry requirements

1.7.2.3.8. Directory of all disk files

1.7.2.4. Operators Manual

1.7.2.4.1. The operators manual shall fully explain all procedures and instructions for the operation of the system including:

1.7.2.4.2. Computers and peripherals

1.7.2.4.3. System start up and shut down procedures

1.7.2.4.4. Use of system, command, and applications software

1.7.2.4.5. Recovery and restart procedures

1.7.2.4.6. Graphic alarm presentation

1.7.2.4.7. Use of report generator and generation of reports

1.7.2.4.8. Data entry

1.7.2.4.9. Operator commands

1.7.2.4.10. Alarm messages and reprinting formats

1.7.2.4.11. System access requirements

1.7.2.5. Maintenance Manual

1.7.2.5.1. The maintenance manual shall include descriptions of maintenance for all equipment including inspection, periodic preventive maintenance, fault diagnosis, and repair or replacement of defective components.

1.7.2.6. As-Built Drawings

1.7.2.6.1. During system installation, the Contractor shall maintain a separate hard copy set of drawings, elementary diagrams, and wiring diagrams of the SMCS to be used for record drawings. This set shall be accurately kept up to date by the Contractor with all changes and additions to the SMCS. In addition to being complete and accurate, this set of drawings shall be kept neat and shall not be used for installation purposes. Copies of the final as-built drawings shall be provided to the end user in DXF format using the latest version of AutoCAD.

1.7.2.7. Quality Assurance

1.7.2.7.1. The manufacturers of all hardware and software components employed in the system shall be established vendors to the access control/security monitoring industry for no less than five (5) years.



1.7.2.8. The security system integrator shall have been regularly engaged in the installation and maintenance of integrated access control systems similar in size and scope to that outlined herein for a period of no less than five (5) years.

1.7.2.9. The security system integrator shall supply information attesting to the fact that their firm is an authorized product dealer for the system proposed.

1.7.2.10. The security system integrator shall supply information attesting to the fact that their installation and service technicians are competent factory trained personnel capable of maintaining the system and providing reasonable service time.

1.7.2.11. The security system integrator shall provide a minimum of three (3) references whose systems are of similar complexity and have been installed and maintained by the security system integrator in the last five (5) years.

1.7.3. Warranty and Maintenance Contract

1.7.3.1. Provide one (1) year warranty from date of acceptance.

1.7.3.2. Provide a three (3) year maintenance plan to support the hardware and software maintenance and upgrades required for continual successful operation of the system.

2. PRODUCTS

2.1. Manufacturers

2.1.1. Security Management Control System Software

2.1.2. These specifications describe a Software House C•CURE 800/8000 Security Management System and define the performance criteria desired for this project. Alternate systems may be submitted but must be shown to be equivalent in performance, functionality and expandability.

2.1.3. Security Management Control System Field Hardware

2.1.4. Software House 9pc/L/8 x and Istar controllers. Card technology shall be proximity with external readers being combination Card and PIN. Internal readers shall be proximity card only without PIN. Cards shall be prepared with color graphics provided by the owner.

2.2. Server Configuration / Host Workstation (One Required)

2.2.1. Minimum CPU Capacities

2.2.2. The Server CPU shall be 100% IBM compatible Pentium PC approved for running the Microsoft Windows 7 (64 bit Supported on Professional and Enterprise platforms) only operating systems. The PC shall have the following minimum configurations dependant upon system capacities:



2.2.3. 2GB RAM

2.2.4. 2.4 GHz processor

2.2.5. 20 GB Hard Drive

2.2.6. DAT tape drive

2.2.7. DVD-ROM drive

2.2.8. 17” SVGA monitor (1024 x 768 resolution @ 65,536 colors)

2.2.9. One USB port

2.2.10. Two serial ports

2.2.11. USB style mouse

2.2.12. Windows 7

2.2.13. Ethernet Adapter

2.2.14. Display Adapter (1024 x 768 resolution @ 65,536 colors)

2.2.15. 56.6K band modem

2.2.16. High Resolution Graphics (Capability)

2.2.17. The system shall support a minimum of 200 user programmable color graphic map displays capable of showing the floor plan, location of alarm device, and alarm instructions. Floor plans shall be created in a .PCX or .BMP format and shall be capable of being imported from other systems. The system shall provide the ability to drop dynamic object icons onto the drawings. These dynamic object icons shall allow the system operator to perform tasks/issue commands related to the object, by double clicking on the icon. All of the graphic maps are to be centralized in the system configuration and shall be displayed on the operator’s workstations. Systems requiring separate display monitors or PC are not acceptable.

2.2.18. Information Storage

2.2.19. All programmed information as well as transactional history shall be automatically stored onto the server hard disk for later retrieval. The system shall warn the operator when the disk space allocation approaches maximum capacity. The system shall allow the system administrator to determine at what percentage of capacity the warnings shall be issued. The system shall further allow the system administrator to define the frequency at which the warnings shall be issued to system operators.

2.2.20. Information Backup/Retrieval

2.2.21. The Server CPU shall be capable of transferring all programmed data and transactional history to tape, floppy disk or CD. All programmed data shall be restorable from disk and/or tape in case of system hardware failure.



2.2.22. Communications Rates

2.2.23. The system shall be capable of supporting a communication rate of 19,200 baud to all access control panels and 10MB Ethernet communications rates to client workstations.

2.2.24. Printers

2.2.25. The SMCS shall support report printers. The report printers may be connected to the parallel port of the Server or Client computers.

2.2.26. Mouse

2.2.27. The SMCS shall only utilize a mouse as the man - machine interface. The mouse shall be used throughout the application.

2.2.28. Local Area Network

2.2.29. The SMCS shall be a Client/Server or Host/Controller architecture configured to operate in a local area network environment. The SMCS Server may be accessed by up to two (2) Operator workstations at any time. The network shall be capable of supporting the TCP/IP protocol.

2.2.30. Printers (One Required in Base Bid)

2.2.31. Supported Printers

2.2.32. The system shall support as a report printer(s) any printer for which a printer driver exists within the Windows operating system. These printers may be dot matrix impact printers, ink jet printers or laser printers.

2.2.33. Real time activity printers shall be form-based printers, i.e. dot matrix. Laser printers shall not be used as real time event printers.

2.2.34. Shared Printers

2.2.35. The system shall provide the ability to generate reports to printers. The printers may be connected to the parallel port of the client and server workstations. The printers shall be configured as shared devices, allowing reports to be generated to any system printer, from any client workstation. The system shall provide the hardware and software support for spooled report printers, at the users option. When configured, the report printer(s) shall be driven from a print queue that is internally maintained by the system software in a manner transparent to the system operator. Once the report has been queued to the spooler, the operator’s terminal shall be released to perform other functions.

2.2.36. Ink jet Printer

2.2.37. At a minimum, the ink jet printer shall be a parallel printer interface, 300 x 300 dpi resolution, and 4 pages per minute print rate.

2.2.38. Laser Printer



2.2.39. At a minimum, the laser printer shall be a parallel printer interface, have a 4 pages per minute print rate, and 2MB memory.

2.2.40. 2.4. Software

2.3. Software Capacities

2.3.1. System software and language development software shall be existing, industry accepted, and of a type widely used in commercial systems. Operating system shall be multi-user/ multi-tasking capable of operating in a non-proprietary CPU. The application software, substantially as offered, shall be written in a high level, industry standard programming language. The system shall be modular in nature, allowing the system capacities to be easily expanded without requiring major changes to the system operation and maintaining all defined system data as well as historical information. ```````

2.3.2. All System functions shall be accessible via point and click mouse control. Systems requiring command string control or complex syntax are not acceptable.

2.3.3. The system software shall include the following features and be configured for minimum:

2.3.4. thirty two ( 32 ) readers, expandable without additional host hardware

2.3.5. ten thousand (10,000) active card holder records

2.3.6. two (2) simultaneous programming locations

2.3.7. nine hundred-ninety nine (999) client PC’s definable on Server

2.3.8. supporting up to seventeen (17) simultaneous printers

2.3.9. one hundred twenty eight (128) time schedules

2.3.10. two hundred fifty six (256) programmable holidays

2.3.11. number of assets 800/1NA

2.3.12. two thousand (2000) clearance codes

2.3.13. one hundred twenty eight (128) input points

2.3.14. one hundred twenty eight (128) output control points

2.3.15. one hundred twenty eight (128) configurable card formats.

2.3.16. forty thousand (40,000) operator accounts with unlimited definable privilege levels

2.3.17. audible alarm annunciation at Operator workstation

2.3.18. unlimited graphic maps to be displayed on the Operator workstation monitor

2.3.19. multi-user, multi-tasking operating system

2.3.20. dial up remote diagnostics



2.3.21. event scheduling

2.3.22. an unlimited number of user defined card holder data fields

2.3.23. an unlimited number of door groups

2.3.24. an unlimited number of areas

2.3.25. card holder access privilege activation date and time

2.3.26. card holder access privilege expiration date and time

2.3.27. Americans with Disabilities Act (ADA) compliance in door and access operation

2.3.28. serial interface with CCTV matrix switchers.

2.3.29. field panel communications through various means including hardwired, dial-up and

2.3.30. Ethernet network.

2.4. Software Operation

2.4.1. The system shall provide a top down configuration methodology. Top down programming shall allow the system operator to configure the system software and hardware configurations in a logical flowing method. The system should allow the operator to start at the highest configuration level of the system and then move down through the lower configuration levels without having to move back and forth between a variety of menus.

2.4.2. The configuration tools shall utilize intelligent configuration controls. The system shall be structured such that the operator shall not be able to perform configuration functions that are not valid based upon the configuration used. For example, if a two (2) door field control panel is being configured, the system shall not allow the operator to configure door number three (3) on that panel.

2.4.3. Where the operator may be presented with a choice of pre-defined objects, the system shall provide a pop-up pick list. The operator may choose an object in the listing by double clicking on the item. If the object has not been pre-defined, the operator may define the new object from the pop-up pick list.

2.4.4. The system shall utilize dynamic icons. The dynamic icons shall change appearance, in both color and icon display based upon the status of the associated object. This appearance change shall occur in real time and shall not require the system operator to perform a screen refresh or exit the current screen.

2.4.4.1.1. Dynamic icons shall be provided to represent:

2.4.5. intelligent field panels

2.4.6. door lock control



2.4.7. alarm input

2.4.8. output control relay

2.4.9. system/alarm event

2.4.10. manual operator actions

2.4.11. For intelligent field panels hard wired to the host computer, the dynamic icons shall reflect the true state of the device represented by the icon. If an operator issues a command to unlock a door, and the field panel which controls that door is not in communication with the host computer, the icon shall not change state or appearance.

2.4.12. Where certain data fields within data screens may contain the same information, the system shall provide the ability to define default settings for these data entry fields. The operator shall be able to change the default setting without impacting objects that have already been defined.

2.4.13. Millennium Compliance

2.4.14. The application software, computer operating system and the field panel operating program shall be millennium compliant. Millennium compliant means the operating systems and programs shall be able to distinguish the year 2000 and beyond and perform control functions based upon dates in the year 2000 and beyond. Provide documentation indicating the Security Management Control System application, computer operating systems and field panel operating programs are all millennium compliant.

2.5. Open Database Connectivity

2.5.1. The Security Management Control System shall utilize a database engine which is Open Database Connectivity (ODBC) compliant. This database engine shall be compatible with 32 bit ODBC drivers. The system shall allow the ability to perform ODBC writes to the system database to import personnel data directly into that database. This data shall then be automatically downloaded to field devices in the same way as manually entered information. See Automated Personnel Data for details.

2.5.2. The software manuals for the Security Management Control System shall provide complete documentation outlining the database schema used within the system. This documentation should be sufficient to allow a person, moderately skilled in databases, to extract information from the Security Management Control System’s databases. The database schema information shall include information on the personnel tables, history and configuration tables.

2.5.3. It shall be possible to use third party report tools, such as Crystal Reports, to generate reports not already provided by the Security Management Control Systems, such as statistical or graphical reports of system activity. The allocation of memory,



between cardholder records and historical event buffering, within each apC/L/8X and Istar through the use of simple menu commands.

2.6. ODBC password protection

2.6.1. Database level Username and Password protection shall be provided for ODBC users. ODBC users will be required to supply a Username and Password when they connect to the SMCS database. Usernames and passwords shall be configured via the user configuration functionality currently available in the Administration utility.

2.6.2. Language Localization

2.6.3. The system shall be configured such that the information presented to system users and operators may be displayed in a language that may be native to the system operator.

2.6.3.1. Supported languages

2.6.3.2. It shall be possible to translate the English text into all languages supported by the ISO-8859-1 (Latin-1) code page. It shall be possible to translate the product into other supported languages, including double-byte languages, but translation will need to be coordinated with the product manufacturer.

2.6.3.3. Simultaneous languages

2.6.3.4. The information presented to a system operator shall be presented in the language defined in the operator profile. If multiple operators are connected to the host server, the information shall be displayed in the language defined in their profile.

2.6.3.5. All system-generated text shall be displayed in the language defined in the operator profile. Data entered by a system operator, such as a Door name, shall be displayed in the language used for entering the data.

2.6.3.6. Messages generated by the system will be displayed in the language set in the International control panel of the server operating system.

2.6.3.7. Reports generated by the system shall be displayed in the language defined during the report generation. When generating a report, the operator shall be able to select from a predefined list, the language to be used when generating the report.

2.6.4. Date format

2.6.4.1. The system shall support the date being formatted in DD/MM/YY or MM/DD/YY, depending upon local date formatting.

2.6.4.2. Hardware Definitions

2.6.5. Menu configuration



2.6.5.1. The System software shall allow for the configuration and programming of the apC/8X and IStar through the use of simple menu commands. The menu commands may be executed by keystroke and mouse point/ click control.

2.6.6. Memory

2.6.6.1. The allocation of memory, between cardholder records and historical event buffering, within each apC/8X and shall be dynamic. Any memory not being used for the storage of cardholder records shall be available for the buffering of historical events.

2.6.7. Database updates

2.6.8. The system software shall download/upload information to/from the apC/8X or Istar automatically while the controller is in communication with the host CPU. A data download shall also be automatically initiated when a controller returns from a communications fault.

2.7. Serial Ports

2.7.1. All serial ports shall be configured from an easy to follow menu. Systems requiring in depth knowledge of the operating system or CMOS setup for port configuration are not acceptable.

2.8. Expansion System expansion must be modular. Additional apC/L/8xs required for incremental system expansion shall be available in two (2) and eight (8) door configurations to allow for maximaum installation flexibility and optimum value. Istar controllers shall be available in 2, 4 and 8 door conigurations.

2.9. Time Specifications

2.9.1. Addressing

2.9.1.1. Each time specification shall be addressed within the system by a unique twenty (50) character user defined name. The use of code numbers or mnemonics shall not be accepted.

2.9.1.2. Holidays -The system software shall allow a minimum of two hundred and two hundred and fifty six (256) holidays and an unlimited number of holidays with per Istar. Holidays shall be considered as additional days of the week and shall have different user programmable parameters from the normal designations for that day. The system shall provide the ability to designate two (2) types of holidays, allowing certain segments of the system to be under holiday control, while other segments of the system are under normal time controls. The system shall allow the holiday to be addressed within the system by the twenty (20) character user defined name assigned to that holiday, i.e. New Year’s Day, can be addressed as New Year’s Day. The use of code numbers or mnemonics in place of the holiday name shall not be accepted.



2.9.1.3. Configuration - Each time specification shall be comprised of user defined time segments. Each time segment shall be day(s) of the week, to include holidays, and a starting time and an ending time. The system shall provide grouping of days, i.e. Mon. - Fri, for easy system configuration.

2.9.1.4. Setup - The system software shall have the capacity for a minimum of one hundred twenty eight (128) user programmable time specifications. Each time specification shall be comprised of allow a minimum of eighteen (18) individual time segments.

2.9.1.5. Assignment - The system shall allow a time specification to be assigned to:

2.9.1.6. apC/L/8x and Istar controllers

2.10. Access Control Clearance

2.10.1. Inputs

2.10.2. Outputs

2.10.3. Doors

2.10.4. Scheduled functions

2.10.5. Alarm events

2.11. Time Zone Management

2.11.1. General - The system shall allow the end user to configure the host server, operator workstations, and field hardware devices, such as apC/8X and Istar controllers, clearances, elevators, some groups and reports to be in different time zones. A time zone is a “time zone” such as Eastern Standard Time and does not indicate a time specification.

2.11.2. Time zone name

2.11.3. Each time zone shall be addressed within the system by a unique twenty (50) character user defined name. The use of code numbers or mnemonics shall not be accepted.

2.11.4. Time zone description

2.11.5. The system shall provide the ability to add time zone description text to each time zone definition. There shall be no limit to the amount of text that can be used to describe the time zone.

2.11.6. Operating system name

2.11.7. The system shall support all time zones supported by the Windows operating system. When defining a time zone to be used by the system, the system shall be provided with a drop down listing of all time zones defined by the Windows



operating system. The operator shall be able to select the appropriate time zone from this listing.

2.11.8. Time zone abbreviation

2.11.9. For display on operator workstations, inclusion in reports, etc, the system shall allow the operator to define a unique three (3) character abbreviation for the time zone.

2.11.10. Interdependency

2.11.11. Objects within the system shall have an associated time zone allowing the object to operate using the local time where the object is physically located. The objects to which time zones shall be associated include operator workstations and apC/8X and Istar controllers.

2.11.12. All items associated with an object shall inherit the time zone of the associated object. For instance, if an apC/8X is assigned to a time zone, all items controlled by that particular apC/8X, such as reader, doors, elevators, Intrusion Zones, inputs and outputs, shall be in the same time zone as the apC/8X. An operator workstation can be associated with a time zone so manual actions performed by an operator at that workstation shall occur in the time zone of the workstation.

2.12. If an operator attempts to configure the system and creates a time zone mismatch, such as defining a clearance code that contains door/time combinations spanning multiple time zones, the system shall provide an informational warning message. The system shall further provide a time zone exception report that shall list the places where the time zone mismatch occurs.

2.13. Assignment -The system shall allow time zones to be assigned to:

2.13.1. apC/8X controllers

2.13.2. clients

2.13.3. time specifications

2.13.4. journal replays

2.13.5. doors and door groups

2.13.6. elevators

2.13.7. clearances

2.13.8. inputs and input groups

2.13.9. outputs and output groups

2.13.10. host server computer

2.13.11. operator workstations



2.13.12. clearance codes

2.14. Operator actions - When an operator performs an action that shall be time controlled, such as unlocking a door, in addition to entering the starting and ending times, the operator shall also enter the associated time zone. Allowing an operator to define the correct times when the action shall occur. For example, an operator in the Eastern Time zone, receives a request from a location in the Central Time zone to unlock a door from 0900 to 0945, the operator can enter these time parameters in the Central Time zone without having to manually offset the time differential.

2.15. Journal replays - When an operator performs a replay from the historical activity journal, the operator shall be presented with the information using the time zone of the specific object in the journal replay message. The three-character abbreviation of the time zone used shall be displayed in the journal message.

2.15.1. The starting and ending dates and times shall be with respect to the chosen time zone. All dates and times displayed in the journal replay shall be with respect to the chosen time zone.

2.16. Event monitoring workstations

2.16.1. The activation date/time and the host-received date/time of activity shall display with respect to the time zone where the operator workstation is located.

2.16.2. The time zone where the operator workstation is located shall be displayed on the operator workstation, along with the current date and time.

2.17. Offset to GMT (Greenwich Mean Time)

2.17.1. For each specified Time Zone, the system shall supply a non-editable field indicating the offset time from Greenwich Mean Time (GMT) in hours and minutes during non-daylight savings time for a Time Zone.

2.17.2. Adjust for Daylight Savings Time

2.17.3. For each specified Time Zone, the system shall supply a non-editable field indicating whether or not the specified Time Zone adjusts for daylight savings time

2.18. Events

2.18.1. Event names - Each event shall be addressed within the system by a unique twenty (50) character user defined name. The use of code numbers or mnemonics shall not be accepted.

2.18.2. System usage - Events shall be used throughout the system to allow the system to react to system activity. For instance an event may be activated based upon an alarm point going into an alarm state. Events shall merge the links to actions, annunciation, communications port failure and timed activation capabilities into one component. An event shall perform multiple functions determined by the actions the user associates with it.



2.18.3. Event priority - The system shall provide from one (1) to eight (8) priority levels; Critical, High, Medium, Low. Each priority level shall include a range of twenty five (25) event priorities, thereby providing two hundred (200) event priorities. The system shall allow the operator to choose an individual priority or one of the eight priority levels.

2.18.3.1. Configuration

2.18.3.2. The system shall allow an event to be configured to:

2.18.3.3. require or not require operator acknowledgment

2.18.3.4. not be cleared unless a log message is entered by the system

2.18.3.5. operator responding to the event

2.18.3.6. display or not display the event activation

2.18.3.7. require the point(s) causing the event activation to reset before the operator may acknowledge the event.

2.18.3.8. display a user defined text message (80 characters) upon event

2.18.3.9. activation

2.18.3.10. display a user defined text message (80 characters) when event is deactivated

2.18.3.11. be associated to a map so the map opens automatically on the Monitoring Station when that event activates

2.18.3.12. configure an event so that if it activates and is unacknowledged for a specified period of time, a second event is activated

2.18.3.13. allow the user to associate and audio wave file with an event

2.18.4. Event instructions - the system shall allow the user to define event instructions that shall be displayed to the system operator when responding to an event activation. There shall be no limit to the amount of text that may be included in the event instructions.

2.18.4.1. Action list - The system shall allow an event to be configured to cause other system actions to occur. These system actions shall include:

2.18.4.1.1. lock door(s) and/or door group(s)

2.18.4.1.2. send email

2.18.4.1.3. grace

2.18.4.1.4. grace all cards

2.18.4.1.5. unlock door(s) and/or door group(s)



2.18.4.1.6. momentary unlock of door(s) and/or door group(s)

2.18.4.1.7. secure door(s) and/or door group(s)

2.18.4.1.8. activate reader(s)

2.18.4.1.9. deactivate readers(s)

2.18.4.1.10. activate event(s) and/or event group(s)

2.18.4.1.11. deactivate event(s) and/or event group(s)

2.18.4.1.12. arm event(s) and/or event group(s)

2.18.4.1.13. disarm event(s) and/or event group(s)

2.18.4.1.14. arm alarm input(s) and/or input group(s)

2.18.4.1.15. disarm alarm input(s) and/or input group(s)

2.18.4.1.16. activate output control relay(s) and/or output control relay group(s)

2.18.4.1.17. deactivate output control relay(s) and/or output control relay group(s)

2.18.4.1.18. momentary activate output control relay(s) and/or output

2.18.4.1.19. control relay group(s)

2.18.4.1.20. automatic display of an associated map on a Monitoring Station

2.18.4.1.21. activation of a second event if the associated first event remains unacknowledged for a specified period of time

2.18.4.1.22. activation when controller reaches a user-specified capacity (i.e. 90% full)

2.18.4.1.23. activation when a controller reaches capacity overflow

2.18.4.1.24. Action reset

2.18.4.1.25. The system shall control, on an action by action basis, whether an operator, responding to an event, may reset an action without acknowledging the event. All actions resulting from an event activation shall automatically reset upon the event being cleared.

2.18.5. Time control - It shall be possible to control via a user defined time schedule the period during which an event shall be armed and therefore capable of being activated by other system actions.

2.18.6. Graphic map display -The system shall allow a graphic map display to be linked to an event. This graphic map shall be available to the system operator to display when responding to the event activation. Graphical maps shall be centralized in the network on a shared disk and be available for display on all operator workstations.



2.18.7. Automatic graphic map display - The system shall allow for the automatic display of a graphic map linked to an event. This graphic map shall be available to the system operator to display when responding to the event activation. At the Monitoring Station, when an event is configured to automatically display a map, a map will pop up each time the event is activated. The map will disappear when the event is acknowledged. Graphical maps shall be centralized in the network on a shared disk and be available for display on all operator workstations.

2.18.8. Event activation for unacknowledged events - The system shall allow the user to specify in an “Unacknowledged” event to activate if an associated event remains unacknowledged for a specified period of time. When an event acknowledgement becomes overdue, its state is changed to “acknowledgement overdue”, and the change is then sent to the journal. The associated “Unacknowledged Event” is then activated

2.18.9. Door Definitions

2.18.9.1. Door names - Each door shall be addressed within the system by a unique fifty (50) character user defined name. The use of code numbers or mnemonics shall not be accepted.

2.18.9.2. Door description - The system shall provide the ability to add door description text to each door definition. There shall be no limit to the amount of text that can be used to describe the door.

2.18.9.3. Construction -Each door shall be comprised of one (1) or two (2) card readers, a door position status alarm point, a request to exit alarm device, PIN pad control, and door lock control output point designator. The use of a second card reader and a request to exit device should be mutually exclusive in the system, such that a door can not be configured with both objects.

2.18.10. Access modes -The system shall allow readers to be configured to operate in either of the following modes:

2.18.10.1. Card Only

2.18.10.2. Card + Personal Identification Number entry

2.18.10.3. Card + Personal Identification Number as specified by time specification

2.18.10.4. Free Access

2.18.10.5. Personal Identification Number is always required

2.18.10.6. It shall be possible to control the access mode assigned to the door by either manual (operator) command, upon event activation or based upon time specification. Each change of access mode shall be logged to the historical activity log and shall be available for report/replay.

2.18.11. Reader states - The system shall support a number of different reader states:



2.18.11.1. Controlled - in this state, the reader shall operate based upon the mode assigned to the door where the reader is located. If the door is in an access control mode, the reader shall read access cards and pass the information to the field panel

2.18.11.2. Disabled - in this state, the reader shall not read cards and shall not pass card information to the field panel. It shall be possible to configure the reader to be disabled, but allow the door to continue to operate, allowing the request to exit device to shunt the door sense monitor point. Operator and events can continue to issue commands to unlock the door.

2.18.11.3. It shall be possible to control the reader state by either manual (operator) command, upon event activation or based upon time specification. Each change of reader state shall be logged to the historical activity log and shall be available for report/replay.

2.18.12. Reader operation (Proximity Readers) - The system shall allow a reader to be configured to operate using the following functions:

2.18.12.1. readers shall read cards while the door is in the open position

2.18.12.2. door lock shall automatically lock upon the door being opened

2.18.12.3. automatic locking of the door lock after the door opened shall be delayed for a user defined time period

2.18.12.4. separate timers for the operation of the door lock and the software shunting of the door position status alarm point. The shunting of the door contact following the presentation of a valid access card or activation of the request to exit device shall be accomplished by software control. The use of a hardware shunt shall not be accepted

2.18.12.5. a separate (alternate) shunt timer shall be available to extend the door shunt time after an access granted access occurs when the card swiped has the ADA flag checked in the card record. Additionally, a second alternate shunt relay shall also be configurable that will be activated when access is granted to a card with the Alternate Shunt/ADA checkbox selected.

2.18.12.6. the user shall be able to specify an shunt expiration output to be triggered a configurable number of hh:mm:ss before the alternate shunt expires

2.19. Door and Window alarms

2.19.1. The door monitoring contact shall be DPDT for use as a door monitoring sensor for access control and as an input to the alarm system where arming and disarming is possible through the use of the Card Reader Keypad and the software. The system shall allow each door to be configured to cause a variety of events to occur based upon activity at that door. The events may be caused by each of the following activities:



2.19.1.1. door held open

2.19.1.2. door forced open

2.19.1.3. reader duress

2.19.1.4. reader communication failure

2.19.1.5. admit access

2.19.1.6. reject access attempt

2.19.1.7. visitor card admit access

2.19.1.8. visitor card reject access

2.19.1.9. noticed card admit access

2.19.1.10. noticed card reject access

2.19.1.11. passback violation

2.19.1.12. PIN required

2.19.1.13. tamper

2.19.1.14. admit causes CCTV action

2.19.1.15. reject causes CCTV action

2.19.1.16. Output Activation - The system shall allow each reader to be configured to cause an output to activate based on activity at that door. The following events may cause an output to activate:

2.19.1.17. Output activation during reader communication failure

2.19.1.18. Output activation while tampered

2.19.1.19. Alternate shunt relay

2.19.1.20. Shunt expiration relay

2.19.1.21. Duress alarm

2.19.1.22. The system shall respond to a duress panic alarm reported from panic button locations for Rooms 105 and 200 and provide an alarm display annunciation on a computer screen on the network.

2.20. Linkage viewing - The system shall provide the operator with the ability to view from the door data screen a listing of all groups that contain the particular door, and a listing of all events that control the door.

2.21. Alarm Configuration



2.21.1. Alarm point name - Each alarm point shall be addressed within the system by a unique twenty (20) character user defined name. The use of code numbers or mnemonics shall not be accepted.

2.21.2. Alarm description - The system shall provide the ability to add a description text to each alarm point definition. There shall be no limit to the amount of text that can be used to describe the alarm point.

2.21.3. Alarm point configuration - The system shall accept as an alarm input: supervised alarm inputs, unsupervised alarm inputs and dedicated alarm points such as device tamper alarms and controller AC power failure.

2.21.4. Alarm arming - Within the system there shall be two (2) separate and distinct states for alarm points. The system shall allow alarm points to be placed OFF/ON LINE. While a point is off line, the system shall not monitor the alarm point or alarm circuit for change of state. When a supervised alarm point is placed on line, the system shall begin to monitor and annunciate supervision alarms for the alarm circuit. The second state for alarm points shall be the ARMED/DISARMED state. When an alarm point is armed, the system shall begin to monitor the alarm device for change of state (normal to alarm and alarm to normal). The alarm device change of state shall be acted upon by the system, based upon the user-defined configuration of the system. Alarm points shall be automatically armed/disarmed during user programmable time periods and may be manually armed/disarmed from any workstation by an authorized system operator.

2.21.5. Additional alerts - The system shall also generate alerts for the following:

2.21.6. Enclosure tampering:

2.21.6.1. controller communication loss

2.21.6.2. Reader tampering

2.21.6.3. Reader communication loss

2.21.6.4. Alarm tampering (supervised)

2.21.6.5. AC power loss

2.21.6.6. Low battery

2.21.7. Alarm supervision - When using supervised alarm points, the system shall monitor for Open Circuit, Short Circuit, in addition to Normal/Abnormal conditions.

2.21.7.1. Linkage viewing

2.21.7.2. The system shall provide the operator with the ability to view, from the alarm input data screen a listing of all groups which contain the particular alarm input and a listing of all events which control the alarm input.

2.21.8. Output Control Relay



2.21.8.1. Output control relay name - Each output control relay shall be addressed within the system by a unique twenty (50) character user defined name. The use of code numbers or mnemonics shall not be accepted.

2.21.8.2. Output control relay description - The system shall provide the ability to add a description text to each output control relay definition. There shall be no limit to the amount of text that can be used to describe the point.

2.21.9. Activation control

2.21.9.1. Output control relays shall be defined as maintained or momentary. Maintained output control relays shall be configured to be activated/deactivated based upon a user defined time schedule, linked to a system event or operator command. Momentary output control relays shall have a user-defined pulse time (defined in 0.1 second increments). It shall be possible to use the momentary output control relays for the momentary control of devices other than door locking hardware.

2.21.9.2. Link programs - The system shall not place limitations upon the number of links that can be defined in the system. The ability to link inputs and outputs that shall be global such that the change of state of an alarm input on one controller could cause the activation of an output on a different controller.

2.21.9.3. Linkage viewing - The system shall provide the operator with the ability to view from the output control relay data screen a listing of all groups that contain the particular output control relay and a listing of all events that control the point.

2.21.9.4. OperatorsPassword - The system software shall be capable of identifying up to forty thousand (40,000) system operators. Passwords shall be up to twenty (20) characters.

2.21.10. Operator name

2.21.10.1. Each operator authorized to operate any portion of the system shall be addressed within the system by a unique twenty (20) character user defined name. The use of code numbers or mnemonics shall not be accepted. The operator name will be used throughout the system to identify commands and functions that the operator has executed.

2.21.10.2. Operator activity -All commands issued by a system operator while monitoring system activity including locking/unlocking doors, event acknowledgment, etc. shall be stored in the historical archive for later recall. The archived command shall include the operator name, time and date the command was issued and the command issued by the operator.

2.21.11. Operator Privileges

2.21.11.1. Privilege control



2.21.11.2. Each operator shall be assigned an operator privilege level. Operator privilege levels define the individual commands within the system which the operator is authorized to execute.

2.21.11.3. Only those commands which an operator is authorized to execute will be available to that operator. If the operator is not authorized to execute a command, that command will be disabled in the displayed toolbar.

2.21.12. Privilege level

2.21.12.1. The system shall provide the ability to group similar privilege controls into a defined privilege level, which can be assigned to system operators.

2.21.12.2. Privilege levels shall be defined and assigned to provide different levels of controls within the system:

2.21.12.2.1. Configuration privilege - shall control what commands, generally related to system data, and operator may execute.

2.21.12.2.2. Event monitoring - shall control which objects within the system the operator can monitor and run reports against.

2.21.12.3. Privilege level construction

2.21.12.3.1. There shall be no limit to the number of privilege levels that can be defined in the system.

2.21.12.3.2. Each privilege level shall be addressed within the system by a unique twenty (20) character user defined name. The use of code numbers or mnemonics shall not be accepted.

2.21.12.3.3. The system shall provide the ability to add a description text to each output control relay definition. There shall be no limit to the amount of text that can be used to describe the point.

2.21.12.3.4. The system shall provide the system administrator the ability to disable a defined privilege level. Any operator who has been assigned this privilege level will be prevented from issuing any commands within the system.

2.21.12.4. Administrative privilege level construction - When constructing the administrative privilege levels within the system, the operator shall assign each administrative command in the system to an assigned access right. These access rights classifications shall be:

2.21.12.4.1. No Access - the operator can not execute these commands

2.21.12.4.2. Read-Only - the operator can open the screen for viewing of defined data. The operator is prevented from making any modification or deletions to the defined data.



2.21.12.4.3. Create/Edit/Delete - The operator can create new objects, edit and delete existing object. The operator however, can not edit the default object definition.

2.21.12.4.4. Full Access - The operator can create new objects, edit and delete existing object. The operator can also edit the default object definition.

2.21.13. When building the privilege level, the system will provide the administrator with a listing of all the commands in the system. By default, all system commands will be assigned to the No Access access right classification. The administrator can then move the command to the appropriate access rights classifications.

2.21.14. Monitoring privilege control construction

2.21.14.1. The monitor privilege shall control which message types and specific objects an operator can view/control while in the event monitoring program. The monitoring privilege shall further control which message types and specific objects an operator may view while running historical journal reports.

2.21.14.2. The monitoring privilege shall also allow the System Administrator to administer access to manual actions an certain menu options of the Monitoring Station. These monitoring privileges shall restrict which security objects a user can control, and which manual actions the user can perform on those objects.

2.21.15. When constructing the monitoring privilege, the administrator shall select the message types the operator can view. These message types shall include:

2.21.15.1.1. operator log in/log out

2.21.15.1.2. card admitted

2.21.15.1.3. card rejected

2.21.15.1.4. operator log message

2.21.15.1.5. object state change

2.21.15.1.6. manual operator actions

2.21.15.1.7. system activity messages

2.21.15.1.8. system error messages

2.21.15.1.9. device activity messages

2.21.15.1.10. device error messages

2.21.15.1.11. asset general activity

2.21.15.1.12. asset authorized movement

2.21.15.1.13. asset unauthorized movement



2.21.15.1.14. asset attempted movement

2.21.15.1.15. asset location update

2.21.15.2. The system administrator shall then define the specific objects, i.e. doors, alarm inputs, outputs, field panels, etc. within the system an operator can monitor.

2.21.15.3. If the operator is not authorized to monitor an object, by extension, the operator shall be restricted from issuing manual commands against the object.

2.21.15.4. Privilege level assignment listing

2.21.15.5. The system shall provide a report listing of all operators who have been assigned a particular privilege level.

2.22. Card Record Definitions

2.22.1.1. Card data

2.22.1.2. The system software shall allow for card numbers up to twenty digits (20) digits (64 bits) on Istar controllers. The apC/L/8x will support ten (10) digits.

2.22.1.3. User defined labels - The system shall allow a privileged system operator to specify field name, field type, field restrictions and whether or not a field is mandatory and/or enumerated. The system shall provide the operator the ability to view the card record layout, including the new labels, before the changes are put into use. The system shall provide the system operator the ability to make fields within the cardholder record not visible.

2.22.2. Card record layout - The system shall allow a privileged system operator to define the placement of the user-defined fields within the personnel data screen.

2.22.3. Personnel records - Personnel records shall be constructed to contain multiple pages of personnel data in system and user defined fields. The personnel data shall consist of a minimum of the following:

2.22.3.1. Card holder name

2.22.3.2. Encoded card number

2.22.3.3. Record ID number (system defined, operator view only)

2.22.3.4. Issue level

2.22.3.5. Ten (10) clearance codes

2.22.3.6. Personal Identification Number (PIN) code

2.22.3.7. Facility number

2.22.3.8. Activation date and time

2.22.3.9. Expiration date and time



2.22.3.10. Unlimited number of user defined fields

2.22.3.11. How many text fields (minimum forty (40) characters per field)

2.22.3.12. How many integer fields (numbers less than 32,767)

2.22.3.13. How many date fields (MM/DD/YY)

2.22.3.14. How many logical fields (selected/not selected)

2.22.3.14.1.1.1.1. Person type

2.22.3.15. Employee

2.22.3.16. None

2.22.3.17. Escort

2.22.3.18. Visitor

2.22.3.19. Contractor

2.22.3.19.1. Status flags

2.22.3.20. Card Expired

2.22.3.21. Card Disabled

2.22.3.22. Card Lost

2.22.4. Access Control Options

2.22.4.1. Activate Alternate Shunt (ADA) Relays

2.22.4.2. Activate Anti-passback Event

2.22.4.3. Notice Accesses

2.23. Asset Manager

2.23.1. First and last name of operator that performed last edit of the card holder information. This shall be defined by the system and shall be view only to the operator.

2.23.2. Date and time last edit was performed on the card holder information. This shall be defined by the system and shall be view only to the operator.

2.23.3. Stored image of the person

2.23.4. Stored signature of the person

2.23.5. Identification badge layout assigned to the person

2.23.6. Date last image was captured/saved

2.23.7. Date last identification badge was printed



2.23.8. Personal Identification Number (PIN) control - The system software shall provide controls such that the Personal Identification Number (PIN) field in the personnel record can not be viewed by system operators. This restriction shall be enforced when viewing the record, running reports containing the PIN field and exporting cardholder data.

2.23.9. When the hidden PIN control is set, the PIN field in the card record shall be displayed as a series of asterisks or bullets.

2.23.10. The system shall prevent running a query to find a card record that matches a particular PIN code.

2.24. Clearance Codes

2.24.1. While the operator is editing a cardholder record, the system software shall provide a browser list of all defined clearance codes. The operator shall be able to assign up to ten of the clearance codes to the cardholder by moving the clearance code name from the defined list to the assigned list.

2.24.2. Controls shall be provided to assign a clearance code to the cardholder, remove an individual clearance code, and remove all assigned clearance codes from the cardholder.

2.24.3. The operator, if authorized, shall also be able to define/edit a clearance from the card holder record screen.

2.24.4. Mandatory data fields -The system software shall provide a means whereby the system administrator may define certain user-defined fields in the personnel record as being mandatory. Personnel performing data entry on the card holder record shall be required by the system to enter information in all field marked by the system administrator as mandatory.

2.25. Choice List fields

2.26. The system software shall provide a means whereby the system administrator may define certain user-defined fields in the personnel record as choice list fields. The system administrator shall be able to define the choice list and the values to be included in the choice list. The operator, when performing data entry, shall be able to choose one of the values defined in the choice list.

2.27. Card record import/export

2.27.1. The system software shall provide means for bulk loading and bulk editing of card records through the use of a data file generated from another source. The external file shall be an ASCII file in comma delimited format.

2.27.2. The system shall also provide the ability to generate the same format file of existing card records, allowing the information in the system to be exported to other computers and applications. The system shall allow the user to select the card records that shall be included in the export file.



2.28. Query capabilities - The system shall provide a card holder selection list, allowing the system operator to choose individual cardholder records from the selection list. The selection list shall provide a quick sorting display of all card holder records. The operator shall be able to set the sorting of the personnel list by:

2.28.1. card holder name

2.28.2. card number

2.28.3. first user defined text field

2.28.4. first user defined integer field

2.28.5. The system shall allow queries to be performed on any field or combination of fields within the card holder record. The system shall allow the queries to be performed based upon partial entry of data in a field, i.e. entering FI in the cardholder name field shall return all records where the name begins with the letters FI.

2.29. Alternate Shunt / Assisted access support (ADA) -The system shall provide the ability to control a door for cardholders requiring assistance or an alternate shunt time. The system shall provide the ability to tag a card indicating the person requires and alternate shunt time. When the person presents their card at a door, and the person is authorized for that door, the system shall unlock the door as normal and shall activate a second output control relay, which may be used to control a door opening device. The shunt time for the door shall be extended beyond the normal shunt time (shunt period defined by system administrator in hh:mm:ss) allowing the person requiring the alternate shunt to pass through the door without generating an alarm.

2.30. Previous activity report - While viewing a cardholder record, the system shall provide the ability to review the previous activity of the cardholder. This shall be accomplished by pressing the “Previous Activity” button on the card holder record screen. They system shall automatically perform a historical search for all previous access activity for the cardholder. This information shall be displayed to the system operator, with the ability to generate a report, either to a file or printer, while viewing the information.

2.31. Enabling a cardholder - The system shall provide the ability to designate a person as a “User” from the Edit Personnel Record screen’s User tab. All other user information features shall be disabled until the Person is designated as a valid user. Once the person is designated as a user in the Personnel Record, the user will be required to supply a username and set the user password before exiting the screen.

2.32. User configuration screen tab - While the operator is editing a cardholder record, the system shall provide the ability to enable a user from the Edit Personnel Record screen’s User tab once the person has been enabled.

2.33. Enabling Breakthrough - The system shall provide the ability designate a user for event breakthrough

3. Execution



3.1. Access Control System - Installation

3.2. General - The contractor shall install all system components and appurtenances in accordance with the manufacturer’s instructions, and shall furnish all necessary interconnections, services, and adjustments required for a complete and operable system as specified and shown. Control signal, communications, and data transmission line grounding shall be installed as necessary to preclude ground loops, noise, and surges from adversely affecting system operation. Provide mounting hardware as required.

3.3. Installation - All low voltage wiring outside the control console, cabinets, boxes, and similar enclosures, shall be plenum rated where required by code. Cable shall not be pulled into conduits or placed in raceways, compartments, outlet boxes, junction boxes, or similar fittings with other building wiring.

3.4. Device Wiring and Communication Circuit Surge Protection

3.5. All inputs shall be protected against surges induced on device wiring. Outputs shall be protected against surges induced on control and device wiring installed outdoors and as shown. All communications equipment shall be protected against surges induced on any communications circuit. All cables and conductors, except fiber optics, which serve as communications circuits from security console to field equipment, and between field equipment, shall have surge protection circuits installed at each end.

3.6. Training

3.6.1. General

3.7. The contractor shall conduct training courses for personnel designated by the owner. Training shall cover the maintenance and operation of the SMCS. The training shall be oriented to the specific system being installed under this contract including central processor. Training manuals shall be delivered for each trainee with two additional copies delivered for archiving at the project site. The manuals shall include an agenda, defined objectives for each lesson, and a detailed description of the subject matter for each lesson. The contractor shall furnish audiovisual equipment and other training materials and supplies as necessary. Where the contractor presents portions of the course by audiovisual material, copies of the audiovisual material shall be delivered to the owner on the same media as that used during the training session. Up to 8 hours of training shall be provided for in the base contract.

3.8. Testing

3.9. General - The contractor shall perform pre-delivery testing, site testing, and adjustment of the completed SMCS. The contractor shall provide all personnel, equipment, instrumentation, and supplies necessary to perform all testing. Written notification of planned testing shall be given to the owner at least fourteen (14) days prior to the test, and in no case shall notice be given until after the contractor has received written approval of the specific test procedures. Test procedures shall explain in detail, step-by-step actions and expected results demonstrating compliance with the requirements of



the specification. Test reports shall be used to document results of the tests. Reports shall be delivered to the owner within seven (7) days after completion of each test.

3.10. Performance Verification Test - The contractor shall demonstrate that the completed SMCS complies with the contract requirements. Using approved test procedures, all physical and functional requirements of the project shall be demonstrated and shown.

3.11. Warranty, Maintenance and Service

3.11.1. Warranty - The SMCS shall be warranted by the contractor for one (1) year from the date of final system acceptance.

3.11.2. Maintenance and Service - The contractor shall provide all services required and equipment necessary to maintain the entire SMCS in an operational state as specified for a period of one (1) year after formal written acceptance of the system, and shall provide all necessary material required for performing scheduled adjustments or other nonscheduled work.

3.11.3. Description of Work - The adjustment and repair of SMCS includes computer equipment, software updates, signal transmission equipment, access control equipment, facility interfaces, and support equipment. Responsibility shall be limited to contractor installed equipment. Provide the manufacturers required adjustments and other work as necessary.

3.11.4. Personnel - Service personnel shall be qualified to accomplish all work promptly and satisfactorily. Provide proof that Service personnel have successfully completed the appropriate level of both hardware and software training offered by the system manufacturer. The owner shall be advised in writing of the name of the designated service representative and of any change in personnel.

3.12. Inspections - The contractor shall perform two inspections at six (6) month intervals or more often if required by the manufacturers. This work shall be performed during regular working hours, Monday through Friday, excluding Federal holidays. These inspections shall include:

3.13. Visual checks and operational tests of the central processor, local processors, monitors, keyboards, system printers, peripheral equipment, SMCS equipment, power supplies, and electrical and mechanical controls.

3.14. Clean system equipment, including interior and exterior surfaces.

3.15. Perform diagnostics on all equipment.

3.16. Check and calibrate each SMCS device.

3.17. Run system software and correct diagnosed problems.

3.18. Resolve previous outstanding problems.

3.19. Emergency Service



3.20. The owner shall initiate service calls when the SMCS is not functioning properly. Qualified personnel shall be available to provide service to the complete SMCS. The owner shall be furnished with the telephone number where the contractor’s service supervisor can be reached at all times. Service personnel shall be at the site within four (4) hours after receiving a request for service. The SMCS shall be restored to proper operating condition after one (1) calendar day.

3.21. Software - The contractor shall provide free software updates for five (5) years and verify operation in the system as required. These updates shall be accomplished in a timely manner, fully coordinated with the SMCS operators, and shall be incorporated into the operations and maintenance manuals and software documentation.

Documents

SECTION 170001 – SECURITY MANAGEMENT CONTROL …pmabids.com/ashland/17_0001_Security_Management_Control_ Sys… · supplies, conduit, raceways, enclosures, mounting hardware, and