TRIMEC ACCESS CONTROL SYSTEM
System Bid Criteria & Product Specifications
1 General Information
1.1 Document Overview
The purpose of this document is to specify the Architectural/Engineering and Bid Criteria for the design, supply and installation of an Access Control System
1.2 Name
[_______________________________________];
Shall be hereinafter referred to in this document as the CUSTOMER and the bid respondents shall be referred to as the CONTRACTOR. The term CUSTOMER includes direct employees and other appointed CUSTOMER agents as architects or consultants. These agents may be requested by the CUSTOMER to represent the CUSTOMER in undertaking certain project tasks.
2 System Architecture1. The Access Control System shall be a modular, networked system that is capable of handling large propriety corporations with multiple remote sites. The system shall also reflect the open-architecture design that is flexible and easily expandable.
2. The software program based on Microsoft tools and standards. The software program shall operate in one of the following environments; Windows XP, 2000 or NT 4.0 using Service Pack 6 or greater using Intel Pentium III Processor or greater.
3. The PC/workstation computer shall be used to program all access control functions, generate reports, display in real-time all or selected alarms, all or selected valid and invalid entry activity, and all internal system status alarms such as communication loss/restore, power loss etc.
4. The system programming should be user friendly and capable of being accomplished by personnel with no prior computer experience. The software shall be of a consistent user interface that is compatible with current software techniques employed by Microsoft and other software developers, namely drop
down menus, drag and drop programming, dialogue boxes, check boxes, etc. The basic user interface shall be consistent with techniques used in the Windows 2000 operating system, or its predecessor, Windows NT and shall also have a manual mode of operation allowing authorized operators to respond to alarm or trouble conditions, unlock doors or override control points.
5. The System shall provide a means for scheduled automatic backups of any or all database system files.
6. The system (single user system or multi user system) shall have the capability to communicate with the controllers via LAN/WAN connections utilizing industry standard TCP/IP communication protocol. The system shall also support direct communication via RS232 protocol.
7. All the system components shall utilize “Distributed Processing” concepts. The distributed processing shall include the ability to download the operator parameters to any field panels, thus allowing the field panel to provide full operating functions independent of the access control system software. The data to be downloaded to the field panels shall contain “rules of access” into individual areas as follows:
a. Areas to which a cardholder may be admitted.
b. The beginning and expiration date/time of access privileges to those areas.
c. The door types to which access is allowed. (E.g. pedestrian entrances, turnstiles, handicap, loading dock etc.)
d. The area state during which access shall be allowed (normal operation, emergency lock down, strike etc).
e. The time zones during which access shall be granted.
8. A provision shall exist to temporarily extend, shorten or block the access granted to a given area or group of areas. If at any time communication between the intelligent field panel and the PC or File Server is interrupted, the field panel shall automatically switch to the off-line mode of operation. During the off-line operation, the field panel(s) shall continue to control access based on the “rules of access” resident in the on-board RAM memory of the field panel. Alarms and access control transactions shall be stored in the memory of the field panel for automatic uploading to the PC/File Server, when primary communication is restored.
3 System Capabilities1. The access control system software shall serve as a database manager, controlling access rights, time schedules, multiple operation modes and alarm point information. Database changes shall be updated or
downloaded automatically from the system server to the field panels. The system server shall determine which changes are to be downloaded to which field panels.
2. The database/cardholder information downloaded from the PC/File Server to the field panels shall be on an intelligent “need to know” basis. That is, only Field Panels containing readers to which a cardholder has access shall receive the data pertaining to that cardholder. Systems that send all the information to all panels in the system shall not be acceptable.
3. All databases should have the ability to add, delete, report, view and edit information.
4. The system shall provide storage of all system transactions in a retrievable file.
5. Log all events by time and date.
6. After the installation, the CUSTOMER shall be able to perform hardware configuration changes. These hardware configuration changes shall include, but not limited to door open time, door contact shunt time, contact point and reader names, when and where a cardholder is valid and the ability to add or modify card database as desired without the service of the CONTRACTOR or the MANUFACTURER.
7. The software shall be user-oriented, with on-line help, instructional prompts and text descriptions.
8. The software shall use drop-down menus for all previously entered system-required data.
9. Duress feature where, when a PIN is used in conjunction with a card read, the numbers of digits are selected at the keypad where the PIN number is a value of one different from the normal PIN.
10. The system shall provide ability to manually operate the system doors. The manual functions include the ability to Lock, Un-Lock, Shunt, Un-Shunt and Return to Time Zone.
11. Support multiple card reader technology including:
• Proximity
• Weigand
• Biometrics
• Magnetic Stripe
• Bar Code
• Keypad
12. The system shall also support multiple languages for international users.
4 Database Design and ManagementThe system shall also support multiple database system, Microsoft SQL Server and Microsoft Access. For flexibility in searching and reporting, the system shall incorporate a contemporary SQL Server relational database from a widely recognized source, such as Microsoft SQL Server.
Systems based upon a vendor proprietary database shall not be considered.
The software shall create independent database tables for selected groups of information (people, badges, time schedules, etc.). Data from the database shall be retrieved through input of a small amount of information into standard data input forms, and then selecting the search option. The results of the search shall be displayed in a list form, and allow the operator to select the record to work on. When a record is selected, it shall be displayed within the data entry form already on the monitor. The software shall provide edit, add, delete, find and print options for records in selected databases. The cardholder record database shall have pre-set fields containing information about badge holders, such as name, address, department, and access rights and personnel type.
The software shall support descriptive names for all database entries. The cardholder record database shall include name, department, employee number, access rights, and address fields. The software shall allow the attachment of an image to the cardholder record, through a standard, fully integrated badge imaging system.
5 ExtensibilityThe system is to be designed with upward growth and expansion in mind. All hardware and software components, offered by the manufacturer, shall be easily portable to and integrated into the largest system configuration offered. The system design shall be consistent within a given system and across that system product family in the interest of minimizing the costs of migration and minimizing, if not totally eliminating the need for operator re-training.
6 System IntegrationThe system shall be complete and fully integrated. It shall combine access control, alarm reporting and acknowledgement and visitor control and reporting
7 System Features and Functionalities7.1 Software
7.1.1 System Communication
1. The system shall provide an interface (Communication Interface Module or CIM) to issue all database changes to the Reader Controllers. This software module also shall have the ability to gather all the information (transactions) from the Reader Controller and store it in proper history files.
2. The CIM shall reside on any workstation or server. On a single user system, the CIM shall reside on a workstation, but on a multi user system that uses multiple CIMs, it shall reside on any workstation or server.
3. The communication between the CIM and the controllers shall be through direct cabling or TCP/IP communication protocol.
4. All serial ports to which the controllers are connected shall be configured using an easy to follow menu. All the COM PORT status messages shall be color-coded.
5. The CIM shall have a specific window, which shall display all the Controllers connected to a COM Port. The user shall be able to select one particular Controller and get all the information pertaining to that device.
7.1.2 Access Rights
The software shall allow for assignment of the access rights to badge holders. The access right is the combination of what “Areas” the badge holder can go (badge and elevator readers) and when the badge holder can go there (time zones). Each badge holder can be allowed multiple “Area” access rights. Each access right shall be allowed to have a different time schedule. The software shall automatically load the proper access rights into each field panel without any operator intervention. There shall be no limits on the number of access rights (who goes where and when) by the system design.
7.1.3 Access Privilege Expiration
There shall be the ability to force an expiration of access privileges in any or all areas with a simple mouse clicking procedure.
7.1.4 Extended Access Privilege
There shall be the ability extend the access privileges in any or all areas with a simple mouse clicking procedure.
7.1.5 Event Triggers
The system shall provide flexibility when associating action items with time zone programmed events, i.e. card transactions with contact reporting and relay activation.
7.1.6 Holidays and Holiday Sets
The system shall allow the user to define the holidays according to the specific CUSTOMER needs. There shall also be the facility to group holiday dates into specific grouping so that, time zone assignments can include all the individual holidays in that. Holidays shall be organized into holiday sets for easy management.
7.1.7 Time zones
Time zone definitions shall include starting time, ending time, days of week and holidays. Time shall be definable in either AM/PM or 24-hour (military) time.
7.1.8 Hardware Definitions
The system shall allow the configuration and programming of the system hardware by easy programming. The user shall be able to define workstations, CIM, CIM Ports, controllers, readers, relays and contact points. All the information entered shall be editable using an easy to use interface.
7.1.9 Device Status
The operator shall have the option to view a single device’s state at any point off time. The user shall be able to request and receive the status from any reader, relay or contact. The status is displayed in a dialog box when it is received.
7.1.10 System Security
The system shall be secure both in its operation and administration. The system shall offer ample flexibility for the administrator to establish and customize any level of security by assigning security permissions to group of operators. The individual operator shall be able to log into the system using a unique operator ID and a password associated with that operator ID. The “Administrator” of the system may set the following rules and standards:
7.1.11 Login Requirements
Logging into the system shall be restricted using User ID and password. The user ID shall be of alphanumeric characters. It shall be a unique ID and cannot be duplicated. Password also shall be of alphanumeric characters but shall be case sensitive. The administrator shall be able to define the expiration date of the password. The administrator shall have the ability to set a pre-determined period of days in advance to warn the operators upon login, as to how many days remain before their passwords
expire. The administrator shall also have the ability to set the password valid for an indefinite amount of time.
The administrator may disable an operator’s password at any time by merely checking a box for that function. The administrator may also set the following conditions for disabling operator passwords automatically.
7.1.12 Cardholder Creation and Management
The system shall provide an easy to use interface to add, delete or modify cardholder information effortlessly. With the use of wizards the user shall be able to input and retrieve data regarding area access, active, retired badges and cardholder categories etc.
1. The cardholder information shall include the following fields for each badge being issued.
a. Cardholder’s first name and last name.
b. Activation and expiration dates (spanning years).
c. A unique encoded number – The number that is encoded within the card and used as a means of identification.
d. A variable keypad number that the user can select from 1 – 9999.
g. Areas and area sets the cardholder has access to.
2. The system shall allow the user to duplicate specific user definable information like area access, categories, badge layout, technology etc whereas, fields like encoded id, stamped id, portrait, signature etc will be unique to each cardholder. This feature shall be available with in a single mouse click.
For example, the system shall allow the creation of a template for all the members of the engineering department or sales department of a company and save it in the database. When the user creates a cardholder and assigns badge, the user shall be able to use the corresponding template.
3. Cardholder data shall be modified and deleted directly from the main screen or by using menu, hot keys or tool bars.
4. Provide functionality to mass change access control fields for activation/expiration dates, access block and antipass back.
5. Provide a cardholder search wizard to make, finding cardholders a simple process.
6. Provide options to include time zone reference.
7. Upon editing card information, the updated information shall be sent automatically to the appropriate access control panel, when hardwired, with no other user intervention. If the scheduler is used, then the card updates shall be sent based on scheduling.
8. The system shall allow the user to add e-mail addresses of the cardholders into the database.
7.1.13 Assigning Area Access
1. Provide functionality to define cardholder’s access to selected Areas and Area Sets.
2. Provide the ability to define specific time of access.
3. Access Control function shall include validation based on time of day, day of week, holiday scheduling and positive verification of site code, card number or PIN number verification.
7.1.14 Portrait Capture
Provide ability to store digital images of the cardholder. One cardholder shall have only one image attached to one record.
7.1.15 Transaction and Alarm Monitoring
1. The software shall include a real time display of all or selected transactions in the system as they occur.
2. The screen shall display substantial information about each transaction (e.g. cardholder, card number, access granted or denied, location, etc.). The operator shall be able to see only those user definable fields, which he has been given permission to view.
3. The Transaction Monitor shall be split into two sections: (1) cardholder transactions, (2) device and operator transactions.
4. The system shall provide a feature that enables the CUSTOMER to set filters for unwanted transactions. The software shall allow the CUSTOMER to select specific cardholders or devices that generate the transactions.
5. The user shall have the ability to customize the online monitoring screen into two individual partitions. One displaying cardholder transactions and the other one displaying device and operator transactions. The operator shall also have the flexibility of turning off any of these transactions and view only one type of transactions.
6. Transactions may be color-coded according to the dictates of the administrator.
7.1.16 Report Generation
The system software shall be able to generate reports of Alarm History, Archive History, Audit Trail, Cardholder Transactions and Transaction History Reports. The user may print and/or export these reports to other applications, store to disk or send to mail recipients, as well.
When requesting a report, the user shall be able to view a "screen preview" of the alarm activity before directing the report to a printer.
7.1.17 System Wide Features
7.1.17.1 Wizards
The software shall provide step-by-step wizards for easy programming of the entire system.
7.1.17.2 Pull down Menus
The system programming shall be menu driven and include tool bar icon for all major options in the menu.
7.1.17.3 Onscreen help
The software shall provide onscreen description of all the actions that the user has to perform while programming the system.
7.1.17.4 Search and Advanced Find
The system shall include a simple search feature for the user to easily find data in the database. The system shall also provide functionality that helps the user to further customize the search criteria and make the search more precise.
7.1.17.5 Right Click Options
The system shall provide right click options for most of the system functionalities.
7.2 Hardware
All the hardware shall be provided with enclosures, which have hinged doors and latches. All the enclosures shall be equipped with tamper switches.
7.2.1 Control Panels
1. The control panels shall be independently programmed, intelligent devices, which shall be able to make decisions at the local level. The system shall provide reader controllers at 2, 4 and 8-reader capacity.
2. The communication between the PC and the control panel shall be directly through a serial port or through an IP addressable modem.
3. The communication between control panel and the reader interface shall be via RS485 protocol.
9. The control panels shall be used with any combination of read head technologies: magnetic stripe, wiegand, bar code, smart card, biometric and more.
14. Each panel shall be addressed within the system by a unique user defined name.
19. The control panel shall have allocated RAM memory to store up to 30,000 card ID numbers up to six digits in length.
20. The control panel shall Store a minimum of 4,000 card access transactions when offline from the network.
22. The control panel shall have a 7-Amp hour Gel Cell battery for standby operation.
24. The control panel shall be able to run on low voltage: 14-17VAC or 12VDC. Power consumption shall not exceed 600 mA (excluding card readers).
7.2.2 Reader Operation
1. Door lock shall automatically lock upon the door being opened.
2. Automatically locking of the door lock after the door being opened will be delayed for a user defined time period.
3. The shunting of the door contact following the presentation of a valid access card or activation of the request to exit shall be accomplished by software control
