Lenel Systems International, Inc. 1212 Pittsford-Victor Road Pittsford, New York 14534 Tel 585.248.9720 Fax 585.248.

9185 www.lenel.com

OnGuard
Technical & Functional Generic Specifications
OnGuard 2009 with Lenel Access Control Field Hardware and Lenel Video Recorders

June 2009

SECTION I - SYSTEM ARCHITECTURE .......................................... 2

A. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. B. 1. 2. 3. 4. 5. 6. 7. 8. a) b) c) d) e) f) g) 11. 12. 13. 14. 15. 16. 17. 18. 19. SYSTEM OVERVIEW.......................................................................................................2 Access Control ...............................................................................................................3 Alarm Monitoring ..........................................................................................................3 Credential Management.................................................................................................4 Digital Video Management ............................................................................................5 Intrusion Detection Management ..................................................................................5 Asset Management .........................................................................................................5 Visitor Management .......................................................................................................5 Remote Access Level Management ................................................................................6 Third Party Interfaces ....................................................................................................6 System Administration ...................................................................................................6 Mobile Enterprise Solutions ..........................................................................................6 Badge Layout Creation and Editing ..............................................................................7 Screens/Forms Creation ................................................................................................7 Graphical Map Creation................................................................................................7 Application Programming Interfaces ............................................................................7 Data Import ....................................................................................................................7 Bi-Directional Data Exchange ......................................................................................7 API Development Toolkit ...............................................................................................8 Server Redundancy ........................................................................................................8 APPLICATION DESIGN ...................................................................................................8 Single, Unified Source Code Set ....................................................................................8 Microsoft Gold Certified Partner ..................................................................................9 Microsoft Windows XP Certification .............................................................................9 Single License Key Systems ...........................................................................................9 Concurrent Licensing.....................................................................................................9 Single Sign-On Support..................................................................................................9 Unicode Support ..........................................................................................................10 Open Architecture ........................................................................................................10 Open Database Connectivity Compliance ...................................................................11 Open Application Architecture ....................................................................................11 Scalability ....................................................................................................................11 Portability.....................................................................................................................12 Network Support ..........................................................................................................12 Video Input Support .....................................................................................................12 Credential Printer Support ...........................................................................................12 32-bit Application ........................................................................................................13 Application Partitioning ..............................................................................................13 Easy to Use, Graphical User Interface ........................................................................13 Support for Microsoft Windows Installer ....................................................................13 Distributed Local Decision Making .............................................................................14 Application Installation ...............................................................................................14 System Management Console ......................................................................................14 System User Feedback Tool .........................................................................................14 Multimedia Integration ................................................................................................14

20. 21. C. 1. 2. 3. 4. 5. D. E. 1. a) b) c) d) d) e) 2. 3. 4. E. F. G. H.

Advanced Network Architecture ..................................................................................14 Object Oriented Programming ....................................................................................15 OPERATING SYSTEM ...................................................................................................15 Interface .......................................................................................................................15 Networking ...................................................................................................................15 Remote Management ....................................................................................................15 Remote Access Services (RAS) .....................................................................................15 Security ........................................................................................................................16 VIRTUAL ENVIRONMENT.............................................................................................16 CLIENT/SERVER RELATIONAL DATABASE MANAGEMENT SYSTEMS .......................16 Preservation of Data Integrity .....................................................................................17 Transaction Processing ................................................................................................17 Enforced Data Integrity................................................................................................17 User-Defined Data Types ............................................................................................17 Encrypted User Defined Fields ....................................................................................17 Defaults ........................................................................................................................18 Rules ............................................................................................................................18 Mature Client/Server Architecture ..............................................................................18 N-tier architecture .......................................................................................................18 Advanced Thin Client Architecture ..............................................................................19 NETWORK DESIGN ......................................................................................................19 GRAPHICAL USER INTERFACE ....................................................................................20 MIGRATION & UPGRADES ..........................................................................................21 SEAMLESS INTEGRATION ............................................................................................21

SECTION II - FUNCTIONAL & OPERATIONAL REQUIREMENTS ................................................................................. 24

A. GENERAL .....................................................................................................................24 B. CUSTOMER RESPONSIBILITIES ...................................................................................24 C. OPERATIONAL CONCEPT ............................................................................................24 D. SYSTEM CAPACITIES ................................................................................................25 E. SYSTEM FEATURES AND REQUIREMENTS ................................................................25 Access Control.........................................................................................................................26 a) Time Zones ..................................................................................................................26 b) Access Levels...............................................................................................................26 c) Temporary Access Levels ............................................................................................27 d) Access Groups .............................................................................................................27 e) Precision Access Levels ...............................................................................................27 f) Holidays .......................................................................................................................28 g) First Card Unlock .........................................................................................................28 h) Database Segmentation ................................................................................................28 i) Field Hardware Communications ................................................................................30 j) Dual Path Field Hardware Communications ...............................................................30 k) Multi-Drop Panel Support............................................................................................31 l) Intelligent System Controller Remote Dial Up Support ..............................................31 m) SYSTEM to Intelligent System Controller Encryption .............................................32

o) Area Control.................................................................................................................32 o) Field Hardware Configuration .....................................................................................36 p) Mustering .....................................................................................................................37 q) Alarm Masking Groups................................................................................................39 r) Global Input/Output/Event Linkage ............................................................................40 s) Cardholder Escort Control ...........................................................................................44 t) Cardholder Use Limits .................................................................................................45 u) Extended Individual Strike Times ...............................................................................46 v) Extended Individual Door Held Open Times ..............................................................46 w) Extended, on Demand, Door Held Open Times ..........................................................47 x) Guard Tour ...................................................................................................................47 y) Elevator Control ...........................................................................................................50 z) Graphical System Overview Tree ................................................................................51 aa) Pre-Alarm ...................................................................................................................51 bb) Alarm/Event Logging ................................................................................................52 cc) Scheduling Utility ......................................................................................................52 dd) Multiple Card Formats ...............................................................................................55 ee) Card Reader Cipher Mode .........................................................................................55 ff) Denied Access Attempts Counter ................................................................................55 gg) Card Reader Time Zone Overrides ............................................................................56 hh) On-Line Context Sensitive Help ................................................................................56 ii) Monitor Zones ..............................................................................................................56 jj) Advanced Field Device Control...................................................................................57 kk) Alarm/Event Routing .................................................................................................58 ll) Text Instructions ..........................................................................................................58 mm) Customizable Voice Instructions ...........................................................................58 nn) Customizable Voice Annunciation ............................................................................59 oo) Alarm Attributes ........................................................................................................59 pp) Alarm-Event Mappings ..............................................................................................61 qq) System Downloads.....................................................................................................61 rr) Card Reader Options ....................................................................................................62 ss) Input Control Module Options ...................................................................................64 tt) Entry/Exit Delay ..........................................................................................................65 uu) Intelligent System Controller Options .......................................................................66 vv) Basic Integrated Intrusion Functionality....................................................................66 2. Alarm Monitoring ........................................................................................................68 a) Alarms Monitored ........................................................................................................68 b) Alarm Annunciation Configuration .............................................................................68 c) Alarm Handling ...........................................................................................................70 d) Current Status Indication .............................................................................................72 e) Pending Alarm Windows .............................................................................................72 f) Device Group Support .................................................................................................73 g) Color Coding for Alarm Priorities ...............................................................................74 h) Color Coding for Acknowledged Alarm Priorities ......................................................74 i) Highlighting of Unacknowledged Alarms ...................................................................74 j) Pre-Defined Canned Alarm Acknowledgment Responses .......................................75

k) Cardholder Record Call-up ..........................................................................................75 l) Inactive Badge Alarm ..................................................................................................75 m) Request to Exit Event.................................................................................................75 n) Real-Time, Live Video User Verification ...................................................................76 o) Cardholder Photo Verification .....................................................................................76 p) Cardholder, Card Reader, or any Field Hardware Device Trace .................................76 q) Single Click/Double Click Device Command Execution ............................................77 r) On the Fly New Login of System Operators .............................................................77 s) Auto Exit to Windows 2008/2003/XP/Vista Login Window ......................................77 t) Grant/Deny Popup Window.........................................................................................78 u) Column Configuration .................................................................................................78 v) Test Mode for Alarm Inputs ........................................................................................78 w) Test Mode for Door Forced Open ................................................................................79 x) Test Mode for Access Grants .......................................................................................79 y) Manual Control ............................................................................................................79 z) Destination Assurance .................................................................................................80 aa) CCTV Interface ..........................................................................................................80 bb) Real-Time, Dynamic Graphical Maps .......................................................................81 cc) Real-Time Graphical System Status Tree and List Window .....................................82 dd) Automatic Credential Deactivation on Lack of Use ..................................................84 ee) Alarm Filtering...........................................................................................................84 ff) Manual Override of Card Readers ...............................................................................84 gg) Alarm Masking ..........................................................................................................84 hh) Manual Overrides of Alarm Points and Relay Outputs .............................................85 ii) On-Line Context Sensitive Help ..................................................................................85 jj) Sorting Capabilities ......................................................................................................85 kk) Masking of Successful Command Acknowledgements .............................................85 ll) Hardware Update Timer ..............................................................................................86 mm) Paging Interface .....................................................................................................86 nn) E-mail Interface .........................................................................................................86 3. Personnel Management and Enrollment .....................................................................87 a) Create and Maintain Cardholder Database ..................................................................87 b) Modify Existing Field Names of SYSTEM Cardholder Form ....................................88 c) Cardholder Active Badges ...........................................................................................88 d) Multiple Active Badges ...............................................................................................89 e) Assign Access Levels ..................................................................................................89 f) Bulk Assignment/Modification/Deletion of Access Levels ........................................90 g) Search Records.............................................................................................................90 h) Bulk Deletion of Cardholder Records..........................................................................90 i) Mobile Badging Operations .........................................................................................91 j) SYSTEM Credentials...................................................................................................91 4. Enrollment & Credential Creation ..............................................................................96 a) Enrollment....................................................................................................................96 b) Image Capture from a Live Video Source ...................................................................97 c) Image Capture from a Scanner or Digital Camera.......................................................97 d) Image Import ................................................................................................................98

e) Auto-crop the Enrollment Photograph .........................................................................99 f) Business Card Scanner Enrollment ..............................................................................99 g) ID Scanner Enrollment ................................................................................................99 h) Biometric Verification .................................................................................................99 1) Federal Agency Smart Credential Number (FASC-N) Standard for Government Badge ID Allocation ..........................................................................................................103 2) PACS Card Holder Unique Identifier Low and Medium Protection Profile Support103 3) Digital Certificate Management .................................................................................104 4) Card Management System Support ...........................................................................105 5) Desktop Smart Card Encoding Support .....................................................................106 6) In-line Smart Card Encoding Support........................................................................106 7) Chromakey .................................................................................................................106 8) Ghosting .....................................................................................................................107 9) Signature Capture.......................................................................................................107 10) Pre-defined Badge Formats......................................................................................107 11) ID Printers ................................................................................................................107 12) Avery Dennison Badge Label Templates ................................................................107 13) Print Limits ..............................................................................................................108 14) Intelli-Check ID Check Integration .........................................................................108 15) Batch Printing ..........................................................................................................108 h) Print Service Bureau Printing ....................................................................................108 i) In-line Magnetic Stripe Encoding ..............................................................................109 j) Image Export ..............................................................................................................109 k) Real Time User Definable Image Compression ........................................................109 l) Crop Window Attributes ............................................................................................110 m) Real Time User Definable Video Input Settings .....................................................110 n) Signature Capture Window Attributes .......................................................................110 o) Image Processing/Effects Gallery ..............................................................................110 p) Bar-code Support .......................................................................................................113 q) PIV card import..........................................................................................................113 r) On-Line Context Sensitive Help ................................................................................114 5. Digital Video Management (With Lenel Network Video Recorders).........................115 a) Overview ....................................................................................................................115 b) Network Interface ......................................................................................................117 c) Seamless Integration with Total Security Knowledge Management Modules ..........117 d) Manufacturer Network Recorders..............................................................................118 e) Digital Video Cameras ...............................................................................................120 f) IP Based Camera Video Surveillance ........................................................................123 g) IP Camera Discovery Utility......................................................................................123 h) Device Linkages.........................................................................................................123 i) Purging .......................................................................................................................124 j) Video Viewing Layouts .............................................................................................124 k) Browser Based Video Viewer ....................................................................................125 l) Alarm Monitoring ......................................................................................................126 m) Intelligent Motion Video Searching.........................................................................135 n) Video Export ..............................................................................................................135

Remote Monitor .........................................................................................................136 Video Authentication .................................................................................................137 On-line Context Sensitive Help .................................................................................137 6. Digital Video Management (With Lenel Digital Video Recorders) ...........................138 a) Overview ....................................................................................................................138 b) Network Interface ......................................................................................................139 c) Seamless Integration with Total Security Knowledge Management Modules ..........139 d) Digital Video Recorders ............................................................................................140 f) Digital Video Cameras ...............................................................................................142 g) Device Linkages.........................................................................................................144 h) Video Archiving.........................................................................................................145 m) Alarm Monitoring ....................................................................................................148 n) Intelligent Motion Video Searching...........................................................................154 o) Video Export ..............................................................................................................154 p) Video Authentication .................................................................................................154 q) On-line Context Sensitive Help .................................................................................154 7. Intelligent Video .........................................................................................................155 a) Overview ....................................................................................................................155 b) Events .........................................................................................................................155 d) Additional Mechanisms .............................................................................................157 e) Intelligent Video Application Server .........................................................................157 f) Seamless Integration with Total Security Knowledge Management Modules ..........158 g) Intelligent Video Overlay ..........................................................................................159 h) Intelligent Video Resolution ......................................................................................159 i) Intelligent Video Imaging Support ............................................................................159 j) Audio Analysis...........................................................................................................159 k) On-line Context Sensitive Help .................................................................................160 8. Intelligent Video Solutions .........................................................................................161 a) Overview ....................................................................................................................161 b) Solutions ....................................................................................................................161 c) Intelligent Video Solution Mode ...............................................................................162 9. Intrusion Detection ....................................................................................................162 a) Overview ....................................................................................................................162 b) System Administration Integration ............................................................................162 c) Alarm Monitoring Integration....................................................................................165 d) Command and Control Functionality.........................................................................171 e) System Events ............................................................................................................173 g) Status Requirements...................................................................................................181 9. Asset Management .....................................................................................................184 a) Overview ....................................................................................................................184 b) Distributed Decision Making .....................................................................................184 c) Asset Technology Independence ...............................................................................184 d) Multiple Reader Technologies ...................................................................................184 e) Seamless Integration ..................................................................................................184 f) Create and Maintain Asset Database .........................................................................185 g) Searching Assets ........................................................................................................186

o) p) q)

h) Asset Classes/Groups .................................................................................................187 i) Enrollment of Assets ..................................................................................................187 j) Assignment of Assets to Cardholders ........................................................................187 k) Asset Tracking/Automatic Assignment of Assets to Cardholders .............................187 l) Asset Tracing .............................................................................................................187 m) Viewing Cardholder Assets .....................................................................................188 n) Asset Management Reports .......................................................................................188 o) Bulk Add Mode..........................................................................................................189 p) Show Assignments 'X' Days Back .............................................................................189 q) On-Line Context Sensitive Help ................................................................................189 10. Visitor Management ...................................................................................................190 a) Overview ........................................................................................................................190 b) Seamless Integration ..................................................................................................190 c) Create and Maintain Visitor Database .......................................................................191 d) Searching the Database ..............................................................................................191 e) Enrollment of Visitors................................................................................................192 f) Business Card Scanner Enrollment ............................................................................192 g) ID Scanner Enrollment ..............................................................................................192 h) Image Capture from a Live Video Source .................................................................192 i) Image Captured from a Scanner or Digital Camera...................................................193 j) Image Import ..............................................................................................................194 k) Signature Capture.......................................................................................................194 l) Assignment of Visitors to Cardholders ......................................................................195 m) Scheduling Visits .....................................................................................................195 n) Visitor Sign In/Sign Out ............................................................................................195 o) Assigning Badge IDs to Visitors................................................................................196 p) Printing a Visitor Badge.............................................................................................196 q) Visit Status User Interface .........................................................................................196 r) E-mail Integration ......................................................................................................196 s) Visitor Reports ...........................................................................................................197 t) Screen Designer Tool .................................................................................................197 u) Seamless Integration to Credential Management ......................................................197 v) Visitor Tracing ...........................................................................................................199 w) Pre-Defined Badge Formats .......................................................................................199 x) On-Line Context Sensitive Help ................................................................................199 y) Browser-based Visit Host Application ......................................................................199 z) Smart Client Based Front Desk application ...............................................................200 aa) Kiosk application .....................................................................................................201 bb) Visitor Administration application ..........................................................................203 11. Remote Access Level Management ............................................................................204 a) Overview ....................................................................................................................204 b) Seamless Integration ..................................................................................................204 c) Password and Permission Privileges ..........................................................................204 d) Browser Based Remote Access Level Management .................................................204 e) Viewing Current Access Level Assignments ............................................................205 f) Removing Access Level Assignments .......................................................................205

g) h) i) j) k) l) 12. a) b) c) d) e) f) g) h) i) j) k) l) m) n) o) p) 13. a) b) c) i) j) k) g) h) i) j) k) l) m) n) o) p) q) r) s) t) u) v)

Assigning Access Levels ...........................................................................................205 Temporary Access Level Assignments ......................................................................205 Bulk Assignment of Activate/Deactivate Dates to Access Levels ............................205 Associated Video .......................................................................................................206 Remote Access Level Management Reports .............................................................206 On-Line Context Sensitive Help ................................................................................206 Third Party Interfaces ................................................................................................207 Overview ....................................................................................................................207 OPC Server Support ...................................................................................................207 OPC Client Support ...................................................................................................207 SNMP Support ...........................................................................................................207 IBM WebSphere Adapter ..........................................................................................208 Microsoft Queues Adapter .........................................................................................208 Fire Alarm Interface ...................................................................................................208 Intercom Interface ......................................................................................................209 Point of Sale Interface ................................................................................................210 Personal Safety System Interface...............................................................................211 Central Station Alarm Receiver Interface ..................................................................213 Smart Card Readers ...................................................................................................213 Smart Card Life Cycle Management .......................................................................214 Otis Compass Destination Entry System Elevator Interface .....................................214 Barco Integration .......................................................................................................214 Onity Integra Offline Locks Integration ....................................................................214 System Administration ...............................................................................................223 System Configuration ................................................................................................223 Pre-defined Database .................................................................................................223 System Configuration Setup Wizards ........................................................................223 Multiple Language Support .......................................................................................223 Single Sign-on Support ..............................................................................................224 Password Privileges ...................................................................................................224 Strong Passwords .......................................................................................................224 System Operators .......................................................................................................224 System Permissions ...................................................................................................225 Network Account Management .................................................................................225 System Operator Activity Logging ............................................................................226 Alarm/Event Activity Logging ..................................................................................227 Encryption of PIN Codes inside the Database Server .............................................228 Access Control Reports..............................................................................................228 On-Line Documentation ............................................................................................241 Ad-hoc Database Report Generator ...........................................................................241 Custom Report Writer ................................................................................................242 System Tape Backup..................................................................................................242 Client workstations ....................................................................................................242 PIN Numbers .............................................................................................................242 List Builder ................................................................................................................243 Archiving ...................................................................................................................243

w) Remote Dial-In Capabilities ......................................................................................243 14. Mobile Enterprise Applications .................................................................................244 a) Application Support ...................................................................................................245 b) Platform Support ........................................................................................................245 c) Mobile Verify.............................................................................................................246 d) Network Connectivity ................................................................................................246 e) Stand-alone Mode ......................................................................................................246 f) Login Privileges .........................................................................................................246 g) User Transactions.......................................................................................................246 15. Badge Layout Creation Module .................................................................................247 a) Badge Layout Objects ................................................................................................247 b) Advanced Database Field Driven Badge Layouts .....................................................247 c) Bar-code Support .......................................................................................................249 d) Object Properties ........................................................................................................250 e) Object List ..................................................................................................................251 f) Color Palette...............................................................................................................251 g) Import/ of Badge Layouts ..........................................................................................251 h) Multiple Badge per Page Printing ..............................................................................251 i) Working with Objects ................................................................................................251 16. Screen Designer Tool .................................................................................................252 a) SYSTEM Cardholder Standard Fields and Objects ...................................................252 b) SYSTEM Asset Standard Fields and Objects ............................................................252 c) SYSTEM Visitor Standard Fields and Objects ..........................................................253 d) SYSTEM Visit Standard Fields and Objects .............................................................253 e) User Definable Fields ................................................................................................253 f) Field Types.................................................................................................................254 g) Field Attributes ..........................................................................................................254 h) Field Styles.................................................................................................................255 i) Field Alignment and Width Tools .............................................................................256 j) Tab Ordering ..............................................................................................................256 17. Map Editor Module ....................................................................................................257 18. Import Module ...........................................................................................................258 19. DataExchange ............................................................................................................259 a) File Imports ................................................................................................................259 b) Exporting Data ...........................................................................................................260 c) Data Expressions ........................................................................................................261 d) Import/Export Filters .................................................................................................262 20. SYSTEM Server Redundancy .....................................................................................263 a) Fault Tolerant Servers ................................................................................................263 b) Hot Standby Server Solution (For Use with LAN based ISCs and SQL Server RDBMS only) ....................................................................................................................263 c) Clustering (FOR USE WITH MICROSOFT WINDOWS ADVANCED SERVER)264 d) Disk Mirroring ...........................................................................................................265 e) RAID Level 10 ...........................................................................................................265 f) Distributed Intelligence ..............................................................................................266 21. DataConduIT .............................................................................................................267

a) b) c) 22. 23.

SYSTEM API Toolkit Operations .............................................................................268 Accepting Custom Incoming Alarms and Events ......................................................268 DataConduIT Devices and Sub-Devices ...................................................................269 Open Protocol Interface ............................................................................................270 Open Supervised Reader Interface ............................................................................271

SECTION III - WORKSTATION & PERIPHERAL REQUIREMENTS ............................................................................... 273

A. 1. 2. 3. 4. 5. 6. B. 1. C. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. D. 1. 2. 3. 4. 5. 6. 7. 8. DATABASE SERVERS ..................................................................................................274 Servers for Windows 2008/2003 Access Control & Alarm Monitoring Systems .......274 Servers for Windows 2008/2003 PRO Access Control & Alarm Monitoring Systems275 Servers for Windows 2008/2003 Credential Management Systems ..........................276 Servers for Windows 2008/2003 Credential Management Systems ..........................277 Servers for Windows 2008/2003 Integrated Systems .................................................278 Servers for Windows 2008/2003 Integrated Systems .................................................279 CLIENT WORKSTATIONS PC SPECIFICATIONS ........................................................280 Client Workstations for Windows 2008/2003 SYSTEMS ...........................................280 CLIENT WORKSTATIONS TYPES ...............................................................................281 Administration............................................................................................................281 Alarm Monitoring ......................................................................................................281 Viewing ......................................................................................................................281 Editing ........................................................................................................................281 Enrollment and Badging ............................................................................................282 Printing ......................................................................................................................282 Asset Management .....................................................................................................282 Digital Video ..............................................................................................................282 Intrusion Detection ....................................................................................................282 Visitor Management ...................................................................................................283 Remote Access Level Management ............................................................................283 Integrated ...................................................................................................................283 PERIPHERALS ............................................................................................................284 Video Camera ............................................................................................................284 Video Capture Board .................................................................................................285 Direct Card Printer....................................................................................................287 Signature Capture Tablet...........................................................................................289 Report Printer ............................................................................................................290 Event Printer ..............................................................................................................291 Modem........................................................................................................................292 Tape Backup System ..................................................................................................293

SECTION IV - ACCESS CONTROL FIELD HARDWARE DEVICES .............................................................................................. 295

A. 1. 2. 2. OVERVIEW .................................................................................................................295 Intelligent System Controller (ISC) ...........................................................................296 Intelligent Dual Reader Controller (IDRC)...............................................................298 Input Control Module (ICM) .....................................................................................301

3. 4.

Output Control Module (OCM) .................................................................................302 Card Readers .............................................................................................................303 a) Standard Card Readers with Wiegand Communications and Clock/Data Output .....303 5. Single Reader Interface Module (SRI) .......................................................................304 6. Dual Reader Interface Module (DRI) ........................................................................305 7. Biometric Reader Interface (BRI) ..............................................................................305 8. Proximity Card Readers ............................................................................................306 a) LenelProx Proximity Card Readers ...........................................................................306 9. Open Card Readers....................................................................................................307 a) Lenel OpenCard Readers ...........................................................................................307 10. Access Control Network Door Controllers or Network Controller/Readers.............308 a) Single door network door controller ..........................................................................308 b) Single door network controller/reader .......................................................................310 11. Field Hardware Power Supplies .....................................................................................313 12. Star Configuration Splitter ..............................................................................................313

SECTION I
SYSTEM ARCHITECTURE

SECTION I

SYSTEM ARCHITECTURE

SECTION I - SYSTEM ARCHITECTURE

A. System Overview The Total Security Knowledge Management Solution (SYSTEM) shall provide a number of functions including the ability to regulate access through specific doors and gates to secured areas of the CUSTOMER facility and provide computer generated color employee and visitor credentials for that use. The SYSTEM shall also record and store digital video of activities occurring in the facility as well as manage and track corporate assets. The SYSTEM must utilize a single seamlessly integrated relational database for all functionality. This integration shall be provided with one operating environment. The SYSTEMs operating environment shall be the fully multi-tasking multi-threading Microsoft Windows 2008/2003/XP/Vista Operating System. The SYSTEM's web enabled client applications shall be capable of running on independent client operating systems including Windows 2008, Windows 2003, Windows XP, Macintosh, UNIX, Linux, and Solaris. The web-enabled applications shall utilize the same common database as the other SYSTEM modules. The SYSTEM shall be written so that all SYSTEM modules (access control, alarm monitoring, credential management, digital video, visitor management, intrusion detection, asset management, etc.) are developed and built from a unified 32-bit source code set. There absolutely shall not be separate source code bases for the individual modules of the SYSTEM. The Total Security Knowledge Management Solution shall allow the configuration of an enrollment & badging client workstation, an alarm monitoring client workstation, an administrative client workstation, an asset management client workstation, a digital video management client workstation, an intrusion detection client workstation, a visitor enrollment client workstation, a remote access level management client workstation, and an integrated client workstation (which shall include any combination of the above client workstations). The SYSTEM shall be expandable to support an unlimited number of individual module or integrated client workstations. All access control field hardware, including Intelligent System Controllers (ISCs), shall be connected to every/any Windows 2008/2003/XP/Vista based access control SYSTEM workstation on the network. The alarm monitoring client workstation must be able to connect to, and monitor, field hardware devices, such as card readers and ISCs. Administrative tasks including defining asset information, access groups, time zones, intrusion detection devices, configuring digital video devices, generating reports, creating maps, etc. shall be provided from any client workstation on the network that is licensed to do so. The enrollment & badging client workstation shall serve as both the credential creation and data input client workstation for the credential management module of the SYSTEM. The visitor management client workstation shall allow for the enrollment of visitors and the scheduling of visits. The integrated client workstation shall allow for any combination of functions of the SYSTEM to be available from the single client workstation. All SYSTEM data must reside on a single database on the network and must be LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 2

SECTION I

SYSTEM ARCHITECTURE

accessible in real time to every/any SYSTEM workstation connected to the network. This shall allow for automatic change propagation to all client workstations on the SYSTEM as well as a common database to consolidate all information and allow for better disaster recovery. The SYSTEM must be designed to perform a wide variety of feature rich functions as part of a Total Security Knowledge Management Solution. These SYSTEM functions are categorized into nineteen primary "system modules" which shall include: A. B. C. D. E. F. G. H. I. J. K. L. M. N. O. P. Q. R. S. Access Control Alarm Monitoring Credential Management Digital Video Management Intrusion Detection Management Asset Management Visitor Management Remote Access Level Management Third Party Interfaces System Administration Mobile Enterprise Solutions Badge Layout Creation Screen/Forms Creation Graphical Map Creation Application Programming Interfaces Data Import Bi-Directional Data Exchange API Development Toolkit Server Redundancy

1. Access Control One of the SYSTEM's primary purposes shall be to provide access control. The SYSTEM shall be able to make access granted or denied decisions, define access levels, and set time zones and holidays. An input/output linkage feature shall allow linking of monitor zone points to output control points within Intelligent System Controllers (ISCs). The SYSTEM shall support features such as area control (two man control, hard, soft, and timed anti-passback), database segmentation, and time zone/holiday overrides. 2. Alarm Monitoring The SYSTEM shall be used for alarm monitoring. Alarms are to be prioritized. The Main Alarm Monitoring Window shall provide information about the time and location of the alarm, along with its priority. The Main Alarm Monitoring Window must be able to sort pending and/or insert new alarms based on any of the following attributes: priority, date/time, alarm description, Intelligent System Controller, Card Reader, Input Control Module, asset name, or cardholder. Date/time sorts must be System Operator selectable to be either ascending or descending and must have the option of displaying the seconds LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 3

SECTION I

SYSTEM ARCHITECTURE

of the minute in which the alarm arrived into the SYSTEM. All columns of information in the Main Alarm Monitoring Window shall be able to be arranged in any order by the System Operator. The SYSTEM must allow unique emergency instructions to be specified for each type of alarm. It shall also allow for the automatic sending of alphanumeric pages or e-mail messages upon alarm arrival. A real-time graphical system status tree on the screen shall indicate if card readers, alarm panels, digital video recorders, video cameras, intrusion detection panels, or Intelligent System Controllers are secured, unsecured, in alarm, or off-line. Output control operations must be available to lock, unlock or pulse control points as a standard feature. An automatic cardholder call-up feature shall allow the quick search and display of images in the database. A System Operator journal shall be available to log important daily events. A trace function shall be available for System Operators to locate and track activity on specific cardholders, assets, video cameras, or card readers. An image comparison feature must be provided for use in conjunction with a CCTV interface. All alarms and hardware icons MUST have the ability to control the associated hardware via right-mouse clicks. The SYSTEM must provide the option to be used as a UL 1981 Classified Central Station Automation System. This option must be classified by Underwriters Laboratories for use as a Commercial Burg Central Station Automation System, to allow the monitoring station where it is used to be made compliant with the UL 1981 standard and listed by UL. This classification shall apply to alarm panels monitored through a connected, UL approved Central Station Alarm Receiver. 3. Credential Management The SYSTEM shall include a seamlessly integrated credential management module. The credential management functionality must allow the enrollment of cardholders into the database, capturing of images, biometric data, and signatures, as well as the import/export of employee data. This functionality shall also allow the System Operator to assign and/or modify the access rights of a cardholder. The SYSTEM shall include a seamlessly integrated state-of-the-art, 32-bit, credential creation and production system. This shall allow for the creation of different badge types based on a database field, the linking of that field to a badge type to automate the process of credential production, and the use of security colors, chromakey, and ghosting, to allow officers to quickly identify personnel access authority. The SYSTEM shall have capabilities for biometric verification. Through the enrollment and comparison of hand geometry (the size and shape of an individuals hand and fingers), or fingerprints, the identity of an individual shall be verified. The SYSTEM shall have the ability to crop and rotate an image automatically based on the orientation of the eyes found in the image. This shall include photographs captured from digital cameras, live cameras, scanned images and imported images.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 4

SECTION I
4. Digital Video Management

SYSTEM ARCHITECTURE

The SYSTEM shall include a seamlessly integrated digital video management module. It shall support real time linkage of digital video clips to their associated alarms from the access control & alarm monitoring system. System Administrators shall configure video segments by specifying pre and post-alarm time marks, then link those defined video segments to specific alarms. Each camera shall be configured to have its own unique set of pre- and post-alarm time marks, video quality settings, and failover recorder. The SYSTEM shall allow for the central administration, monitoring, and archiving of digital video and the associated cameras. The SYSTEM shall support Digital Video Recorders from multiple manufacturers. The SYSTEM shall also support IP based digital cameras and digital video encoders/servers from multiple manufacturers for advanced video surveillance. The SYSTEM shall support MJPEG, MPEG4 simple profile encoding standards and frame rates to include both PAL and NTSC respectively at maximum of 25/30 frames per second. In addition, the SYSTEM shall support a network based digital video recorder. 5. Intrusion Detection Management The Intrusion Detection Management System shall provide advanced, seamless integration with Intrusion Detection Panels from Bosch (D9412 and D7412), Detection Systems (7400xi and 7400xi 4+), Honeywell (Galaxy 8, 18, 60, 128, 500, 504, 512), and Guardall (xL, PX, QX, and RX), allowing customers to monitor intrusion detection alarms inside the SYSTEM alarm monitoring application, in addition to giving CUSTOMER command and control of supported intrusion detection devices (such as arming and disarming an area). Once alarms are brought into the SYSTEM, they shall be linked to digital video, global I/O activity can be triggered, and they shall be stored in the SYSTEM audit trail. In addition, System Operators shall monitor the status of intrusion detection devices from the SYSTEM Alarm Monitoring Workstation. 6. Asset Management The SYSTEM shall include a seamlessly integrated asset management module to include real time management and tracking of CUSTOMER assets. The SYSTEM shall allow for the centralized management of assets. System Administrators shall be able to generate reports on current asset assignments as well as the history of cardholder assignments for assets. The SYSTEM shall also be able to restrict assets from passing through checkpoints with unauthorized personnel and report assets that pass through checkpoints with authorized personnel. The SYSTEM shall also allow specified readers to require an authorized asset before granting access. 7. Visitor Management The SYSTEM shall include a seamlessly integrated visitor management module. The visitor management module shall be a desktop-based application utilizing technology that allows CUSTOMER to enroll and track visitors of the organization.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 5

SECTION I

SYSTEM ARCHITECTURE

It shall allow CUSTOMER to enroll visitors, sign them in or out, assign them to an employee, capture a photo, capture a signature, and track the visitors as they move throughout the facilities. It shall allow System Operators to enter and pre-schedule visits. It shall allow System Operators to print visitor badges and shall incorporate complete audit trail and reporting capabilities. 8. Remote Access Level Management The SYSTEM shall include a seamlessly integrated remote access level management module. The remote access level module shall be a desktop-based application technology that allows CUSTOMER managers to assign and remove access levels to/from cardholders in the existing SYSTEM database. All transactions relating to the adding and/or removal of access levels shall be recorded complete with a time/date stamp and the System Operator who made the change. 9. Third Party Interfaces The SYSTEM shall integrate with a number of third party hardware and software products. The SYSTEM shall provide an industry standard OPC Server utility to allow the export of any and all SYSTEM alarms and events to industry standard OPC Clients, such as building automation and/or process control systems. The SYSTEM shall also provide the ability for an Alarm Monitoring Workstation to function as an OPC Client that shall accept alarms and events from industry standard OPC Servers, such as those from Building Automation/Process Control Systems. The SYSTEM shall provide seamless integration with fire alarm systems such as Pyrotronics and Notifier, personal safety systems such as Visonic Spider Alert, intercom systems such as Zenitel Alphacom/AlphaNet, and central station alarm receivers such as Bosch 6500/6600 and Osborne Hoffman 2020. The SYSTEM shall allow alarms and events from the third party systems to report into the same Main Alarm Monitoring Window as access control alarms. Third party interface hardware shall be configured in the SYSTEM access control module. In some cases, System Operators shall be able to control third party hardware devices from the Alarm Monitoring Workstation. Third party hardware alarms and events shall be stored in the SYSTEM database for audit trail and reporting purposes. 10. System Administration System Administrative tasks such as defining client workstation & System Operator permissions set-up, access groups, time zones, reports, maps, etc. shall be provided from any client workstation on the network. Initial setup of the cardholder screen layout shall occur on the database server. The SYSTEM shall support the use of strong passwords. 11. Mobile Enterprise Solutions The SYSTEM shall support a Mobile Enterprise Architecture for customers with mobile computing needs. Mobile Enterprise functionality shall be a seamlessly integrated, robust solution that transports virtually all SYSTEM client functions to a wearable, portable computer. The portable computer shall connect to the network and SYSTEM Server via

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 6

SECTION I

SYSTEM ARCHITECTURE

802.11B wireless Ethernet on-line, or shall operated as a standalone solution that synchronizes with the SYSTEM Server on an operational basis. 12. Badge Layout Creation and Editing The SYSTEM shall provide a Badge Layout Creation and Editing Module to allow for the creation of custom badge designs to be created by the CUSTOMER. The SYSTEM shall support credit card, government, and custom credential sizes in either a landscape or portrait format and shall support double sided and edge-to-edge printing. 13. Screens/Forms Creation Should the SYSTEM standard fields not be suitable, the SYSTEM shall provide a Forms Designing and Editing Module that gives System Administrators the ability to modify any standard field to customize the cardholder, asset, and /or visitor forms, as desired. The SYSTEM shall also allow System Administrators to add custom fields in addition to any standard fields on a minimum of 32 pages each of information for cardholder, visitor, and visit related data. User defined fields absolutely shall not be pre-defined, meaning only the labels can change while the properties cannot. System Administrators shall have a minimum of 96 pages of which to design their cardholder, visitor, and visit screens with standard and custom fields. 14. Graphical Map Creation The SYSTEM shall provide Graphical Map Creation and Editing Software that must allow System Administrators to import customized map backgrounds of their facility and to attach custom icons to those maps. 15. Application Programming Interfaces The SYSTEM shall provide a set of standard Application Programming Interfaces (API's) and supporting documentation that allows hardware manufacturers and software application developers to integrate their products into the SYSTEM. The Application Programming Interfaces shall allow requests from CUSTOMER to integrate a third party hardware or software solution based on SYSTEM open architecture and SYSTEM device independence. 16. Data Import The SYSTEM shall support an import utility that will allow the CUSTOMER or VAR to import cardholder information into the SYSTEM database. This shall allow the CUSTOMER or VAR to pre-populate the SYSTEM database with existing cardholder data and/or add new records to the existing SYSTEM database. 17. Bi-Directional Data Exchange The SYSTEM shall support a real time, bi directional data interface to external databases such as Human Resources, Time and Attendance, Food Service Systems. The interface shall allow data to be imported into or exported out of the SYSTEM in real time or in a batch mode basis. Data used for import shall be retrieved directly from an external LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 7

SECTION I

SYSTEM ARCHITECTURE

database or through an import file. Data provided for export shall be applied directly to an external database or through an export file. Any data shall be imported or exported including image data. The file used for import or created by export shall have the ability to be structured in a wide variety of ways, but shall always be in ASCII text format. The SYSTEM shall also support a one step download and distribution process of cardholder and security information from the external database to the SYSTEM database, all the way down to the Intelligent Field Controller (ISC) database. This shall be a guaranteed process, even if the communication path between the SYSTEM database server and the ISC is broken. If the communication path is broken, the data shall be stored in a temporary queue and shall be automatically downloaded once the communication path is restored. 18. API Development Toolkit The SYSTEM shall allow, through API toolkits, System Administrators to expose specific SYSTEM data and events that are relevant to IT information or other third party systems. Conversely, the SYSTEM shall allow, through these same API toolkits, System Administrators to accept and process information exposed from the IT information or other third party systems. This shall permit System Administrators to develop scripts and applications that allow events in either the IT domain to cause appropriate actions in the Security domain, and vice versa. 19. Server Redundancy The SYSTEM shall support a fault tolerant server and redundant database architecture. It shall also allow for a server clustering architecture. It shall allow for normal operations to occur in the event that the Database Server fails. In the event of a server failure, the switch over to a backup server from a primary server shall be automatic and not impede the operation of the SYSTEM. B. Application Design 1. Single, Unified Source Code Set All SYSTEM application modules, features, and functions MUST be generated from a single source code set. In addition, the source code must be designed using objectoriented software development techniques and compile into native 32-bit applications. The access control, alarm monitoring, credential management, digital video management asset management, intrusion detection management, visitor management, and remote access level management modules of the software shall be created from this single source code set. There absolutely shall not be separate source code bases for separate modules. Thus, a single manufacturer must develop all SYSTEM modules. This shall allow for the ease of maintaining the SYSTEM and allow for the ease of future upgrades and enhancements. All SYSTEM features and functionality listed in the proceeding pages shall ship with each SYSTEM. Features and functionality available to

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 8

SECTION I

SYSTEM ARCHITECTURE

CUSTOMER shall be determined through licensing and shall be controlled by a hardware/software license key. 2. Microsoft Gold Certified Partner A Microsoft Gold Certified Partner must develop the SYSTEM. 3. Microsoft Windows XP Certification The SYSTEM shall have passed Microsoft Windows XP certification testing and shall be officially Microsoft Windows XP Certified. The Microsoft Windows XP Certification Program for applications shall help CUSTOMER identify reliable and manageable applications. The SYSTEM, that shall meet the specifications for Windows XP certification, shall provide a robust, self-repairing installation that shall help minimize conflicts among shared components. This shall enable better co-existence of applications, facilitate easier software deployment, and reduce support and training costs. 4. Single License Key Systems The SYSTEM shall only require a single license key to be present on the database server for the SYSTEM to operate. The license key shall either be a physical device or a software license key. The SYSTEM shall allow the SYSTEM USER the ability to activate, return, or repair the software license key. The software license shall only be used on a physical computer or in a VMware virtual environment. License keys shall not be required at the client workstations. The license key on the database server shall determine the number of client workstations that shall be able to connect to the SYSTEM as well as all SYSTEM functionality. An alarm shall be generated in the alarm monitoring application as the license expiration date approaches. 5. Concurrent Licensing The SYSTEM shall support concurrent licensing with respect to client licenses. CUSTOMER shall purchase a fixed number of client workstation licenses (or connections) that shall be programmed into the database server license file. The SYSTEM shall be installed on any number of client workstations in the CUSTOMER facility. Then, any of the client workstations that have the SYSTEM software installed shall have the ability to connect to the database server as long as the maximum number of concurrent connections purchased has not been reached. Connections shall be licensed on a per module basis. This shall provide CUSTOMER with great flexibility in system design and layout. 6. Single Sign-On Support The SYSTEM shall provide support for single sign-on capability. Single sign-on shall allow System Administrators/System Operators to authenticate into SYSTEM applications using their Windows domain account. Sign sign-on shall support the following scenarios:

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 9

SECTION I
1.

SYSTEM ARCHITECTURE
Allow System Administrators/System Operators to interactively run SYSTEM applications without having to enter a username or password. This shall make administration of the SYSTEM easier since maintenance of separate SYSTEM usernames and passwords is not required.

2. Allow SYSTEM API scripts to authenticate. These scripts shall be run using a Windows account allowing a seamless and secure way to authenticate the account and restricting the script to those actions that the user is permitted to perform. 7. Unicode Support The SYSTEM shall be designed to support Unicode allowing for easier translation into specific languages. The SYSTEM shall be available in a minimum of the following languages (call factory for specific SYSTEM version information): 1. Arabic 2. Chinese 3. English 4. French 5. German 6. Hebrew 7. Italian 8. Korean 9. Russian 10. Spanish 11. Swedish 8. Open Architecture The SYSTEM shall have an open architecture design. It shall be a true open architecture design and support industry standards for databases, networks, credential printers, and video cameras. No customized or proprietary PC or credential creation software or hardware shall be required to operate the SYSTEM. The SYSTEM shall be both scalable and portable to give CUSTOMER the ability to increase performance based on CUSTOMER requirements. This shall give CUSTOMER maximum flexibility and room for unlimited growth.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 10

SECTION I
a) Open Database Connectivity Compliance

SYSTEM ARCHITECTURE

The SYSTEM shall be Open Database Connectivity (ODBC) compliant. The SYSTEM shall support a relational database management system with the proper 32-bit ODBC drivers. Examples of these databases include, but are not limited to, Microsoft SQL Server 2005 or SQL Server 2008 or Oracle Server 10g or 11g. The SYSTEM shall be designed so that two methods of integrating these aforementioned relational database management systems are possible. The first method shall be to use one of these databases as the SYSTEMs dedicated database server, meaning only the SYSTEMs information is stored in the database. The other method is to use one of these databases as a non-dedicated database server and attach SYSTEM database tables to the existing database that shall be used by one or many systems. The SYSTEM must be installed and operational on at least two (2) distinctly different relational database management systems in the field. For example, the SYSTEM must have at least one customer that is running Microsoft SQL Server 2005 or Microsoft SQL Server 2008 and at least one other customer that is running Oracle Server 10g or 11g. Both customers MUST be using the SAME VERSION AND MODEL SOFTWARE. b) Open Application Architecture The SYSTEM shall support an Open Application Architecture. It shall provide a set of standard Application Programming Interfaces (API's) and supporting documentation that allows hardware manufacturers and software application developers to integrate their products into the SYSTEM. The Application Programming Interfaces shall allow requests from CUSTOMER to integrate a third party hardware or software solution based on SYSTEM open architecture and SYSTEM device independence. Examples of hardware interfaces include fire alarm panels, intercom systems, central station alarm receivers, and personal safety & asset devices. Examples of software interfaces include time and attendance systems, human resource databases, and risk management systems. c) Scalability The SYSTEM shall be scalable to support Symmetric Multi-Processing (SMP) machines. The Relational Database Management System (RDBMS) within the SYSTEM shall use a single-process, multi-threaded architecture known as Symmetric Server Architecture, which provides scalable, high system performance with very efficient use of SYSTEM resources. The SYSTEM shall provide Symmetric Multiprocessor Support, allowing it to execute threads in parallel on multiple CPUs. The RDBMS shall use native

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 11

SECTION I

SYSTEM ARCHITECTURE
Windows 2008/2003/XP/Vista threads and it shall automatically scale to multiprocessor hardware with no special configuration or programming required.

d) Portability The SYSTEM shall be portable across multiple platforms to take full advantage of multiple hardware architectures, without changing SYSTEM software. The SYSTEM software shall work on platform architectures including Intel x86, Digital Alpha AXP, and Symmetric Multi-Processing machines. e) Network Support The SYSTEM shall be designed to support any industry standard network protocol and topology listed below: 1. TCP/IP 2. Novell NetWare (IPX/SPX) 3. Digital PATHWORKS 4. Banyan VINES 5. IBM LAN Server (NetBEUI) 6. IBM SNA Networks 7. Microsoft LAN Manager (NetBEUI) 8. NFS Networks 9. Remote Access Service (RAS) via ISDN, x.25, and standard phone lines f) Video Input Support The SYSTEM shall support any industry standard video input source that utilizes a Red/Green/Blue (RGB), Composite, or S-Video signal. The SYSTEM shall allow cardholder, visitor, and asset photos to be taken from any one of the live video signals listed above or to be scanned in using any industry standard scanning device that utilizes an industry standard TWAIN interface. SYSTEM support for other methods of inputting a cardholders, visitors, and assets photo, such as through the use of an industry standard digital camera with an industry standard TWAIN interface, or by importing a photo from any industry standard image file format, shall also be available. g) Credential Printer Support The SYSTEM shall be designed to support any industry standard thermal dye or re-transfer credential printer with a Microsoft certified industry standard Windows 2008/2003/XP/Vista driver. The SYSTEM shall also support any ink

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 12

SECTION I

SYSTEM ARCHITECTURE
jet, laser, or dot matrix printer with a Microsoft certified industry standard Windows 2008/2003/XP/Vista drivers.

11. 32-bit Application The SYSTEM shall operate on a Windows 2008/2003/XP/Vista multi-tasking, multithreading 32-bit or 64-bit operating system. The SYSTEM software shall be a true, native 32bit application built from the ground up for Windows 2008/2003/XP/Vista. The SYSTEM absolutely SHALL NOT be ported over from another operating system (i.e. UNIX, Windows, or OS/2) and shall not be a Win-16, UNIX or OS/2 program utilizing a Windows 2008/2003/XP/Vista Server. 12. Application Partitioning The SYSTEM shall employ an application partitioning design so that applications are broken into separate distinct programs capable of running independent of other SYSTEM applications. Applications shall include, but not be limited to, alarm monitoring, system administration & configuration, credential management, access panel drivers, asset management, import modules, digital video management, credential designing modules, visitor management, remote access level management, and cardholder forms designing modules. Each client workstation shall have the ability to be installed with any combination of the above listed modular applications. A system written as a single monolithic code base shall not be acceptable. 13. Easy to Use, Graphical User Interface The SYSTEM shall support a user friendly, Windows graphical user interface that shall be intuitive. All messages and interface text shall support localization. Selection and use of any language supported by MANUFACTURER other than English shall be accomplished with the installation of the SYSTEM language pack in addition to the core SYSTEM. The SYSTEM shall support English, Arabic, French, Chinese (Simplified), Chinese (Traditional), Croatian, Czech, Dutch, Finnish, French, Hebrew, Italian, Japanese, Korean, Portuguese (Brazilian), Russian, Spanish, and Swedish language packs. All functions shall be either keyboard or mouse driven to allow the System Operators to choose the method of navigating through the screens. In the alarm monitoring module of the SYSTEM software, all major functions (opening a door, acknowledging alarms, launching video, etc.) shall be accomplished in one or two mouse clicks. This shall allow for ease of operation, especially in emergency situations. The SYSTEM shall support Windows XP/Vista themes for buttons, lists, trees, check boxes and radio buttons. The SYSTEM shall support Office themes for menus and toolbars. The SYSTEM colors scheme shall be based on the active Windows XP/Vista theme. The SYSTEM shall also support the new menu and toolbar based on Office theme, when the Windows XP/Vista themes are disabled. 14. Support for Microsoft Windows Installer The SYSTEM shall support Microsofts Windows Installer that shall allow efficient system deployment. This means that the SYSTEM shall be loaded onto a server running LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 13

SECTION I

SYSTEM ARCHITECTURE

Windows Installer and all client workstations and any future upgrades shall be installed from the server utilizing network communications. 15. Distributed Local Decision Making The SYSTEM shall employ a distributed architecture so that all cardholder, visitor, and asset access decisions are made locally at the Intelligent System Controller (ISC). 16. Application Installation The SYSTEM shall support a simplified installation procedure using Installation Wizards that guide System Administrators through the installation of the database server and any client workstations. The SYSTEM shall automatically detect previous versions installed on the client workstations for fast and efficient upgrade installations. 17. System Management Console The SYSTEM shall provide a utility that provides system information and access to log files that can be used to aid in troubleshooting SYSTEM issues. 18. System User Feedback Tool The SYSTEM shall provide a tool to allow the SYSTEM USER the ability to provide feedback from a menu item available in multiple SYSTEM applications. The tool shall launch a web feedback form that allows the SYSTEM USER to send feedback about the SYSTEM to the MANUFACTURER. 19. Multimedia Integration The SYSTEM shall extensively integrate and utilize multimedia throughout the SYSTEM software. Real-time, dynamic graphical maps mean that the map screen does not have to re-paint or refresh each time a new alarm or event condition occurs. Map device icons shall also dynamically change shape based on the state of the device. The SYSTEM shall support a CUSTOMER customizable voice alarm annunciation and a flashing colored system icon for each alarm in the SYSTEM. The SYSTEM shall also support customizable voice instructions so that each alarm or event in the SYSTEM can have both sets of text instructions and pre-recorded audio voice instructions. Real-time live user video verification seamlessly integrated into alarm monitoring shall also be available to view cardholder activity in high priority areas. 20. Advanced Network Architecture The SYSTEM shall be designed to support advanced distributed network architecture, whereas Intelligent System Controllers do not need to be home-run wired back to the database server. Intelligent System Controllers shall be wired to any Windows 2008/2003/XP/Vista based PC that is licensed to run the SYSTEM software. Also, Intelligent System Controllers shall be connected to a Local Area Network/Wide Area Network via industry standard TCP/IP communication protocol. Network based Intelligent System Controllers shall be able to communicate back with the database server through industry standard network switches and routers and shall not have to be on the LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 14

SECTION I

SYSTEM ARCHITECTURE

same subnet. The SYSTEM shall also support dual path upstream communications between the ISC and client workstations/database server. Secondary communications paths shall include direct connection (RS-232/485), network (TCP/IP) or dial up connections. As such, any alarm in the SYSTEM shall be routed to any client workstation(s) on the network, regardless of the Intelligent System Controller that generated the alarm. 21. Object Oriented Programming The SYSTEM shall be designed using the latest programming techniques and advanced 32-bit programming tools to optimize SYSTEM performance. Thus, the SYSTEM shall be designed utilizing object oriented programming. This shall give the SYSTEM a modular design and allow the CUSTOMER to pick and choose the desired functionality required. Object Oriented Programming shall allow for ease of SYSTEM maintenance and will allow the SYSTEM to be easily expanded and upgraded as the CUSTOMER needs grow. C. Operating System The SYSTEM shall support the 32-bit Microsoft Windows 2008/2003/XP/Vista multitasking, multi-threading operating system. The SYSTEM must meet the below requirements for a Windows 2008/2003/XP/Vista based system. 1. Interface The operating system shall offer the look and feel of the Windows operating system to enhance usability and efficiency. The operating system shall come complete with administrative wizards and interactive help to guide System Administrators in the configuration of the SYSTEM. 2. Networking The operating system shall support a minimum of 15 networking protocols including, but not limited to, TCP/IP, IPX/SPX, RAS, and NetBEUI. The SYSTEM shall also support peer-to-peer and FTP server capabilities. 3. Remote Management The operating system shall utilize remote management utilities such as event viewers and performance monitors to fine tune and optimize the operating system that will in turn optimize the SYSTEM. It shall support both dial-out capabilities to remote servers as well as remote dial in capabilities. 4. Remote Access Services (RAS) The operating system shall support full remote diagnostics abilities through its remote access services. Full network functionality shall be available over remote links using NetBEUI, IPX/SPX, and TCP/IP protocols. Dial in capability to remote Windows 2008/2003 Servers using remote access service shall also be available. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 15

SECTION I
5. Security

SYSTEM ARCHITECTURE

The operating system shall support multiple user profiles on the same client workstation so System Administrators can assign which programs shall be available to System Operators based on their operating system user log-on. Local desktop security shall be available through User ID and required password log-on. The operating system MUST also offer government C-2 level certifiable security. The SYSTEM shall support a data encryption utility. In utilizing encryption technologies, data communication shall be protected between workgroups, local area network computers, domain clients and servers, branch sites which may be physically remote, extranets, roving clients, and remote administration of computers. Encryption shall be achieved through either Windows Internet Protocol Security (IPSec), which is a part of Microsoft Windows 2008/2003 Server/Professional, or through IRE SafeNet/Speed. IPSec shall support two encryption modes: transport and tunnel. Using transport mode, end-to-end security from client-to-server, server-to-server, and client-to-client shall be accomplished. Using Layer Two Tunneling Protocol secured by IPSec, secure remote access from client-to-gateway over the Internet shall be accomplished. IRE SafeNet/Speed shall automatically encrypt user data with the Triple-Data Encryption Standard (Triple-DES) for public key encryption. The encryption that occurs with the SYSTEM shall be broken down into two main segments: peer-to-peer (which occurs between a workstation within the secured area and a server outside the secured area) and peer-to-panel (which occurs between a workstation within the secured area and the panel via the IRE SafeNet/Speed device). These segments shall utilize different keys to encrypt or decrypt the data. D. Virtual Environment The SYSTEM shall support the loading of the application on a virtual environment. The SYSTEM shall allow the Communication service to run in a virtual environment. The guest operating system must meet the requirements of the SYSTEM operating system. The SYSTEM shall support the use of VMware Server. VMware is supported for running the SYSTEM and for use as the Database Server or the Communication Server. E. Client/Server Relational Database Management Systems The SYSTEM shall support industry standard Open Database Connectivity (ODBC) compliant relational database management systems. This shall include relational database management systems such as Microsoft SQL Server 2005 and Microsoft SQL Server 2008 and Oracle Server 10g, and 11g.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 16

SECTION I

SYSTEM ARCHITECTURE

The SYSTEM must be installed and operational on at least three (3) relational database management systems in the field. For example, the SYSTEM must have at least one customer that is running Microsoft SQL Server 2005 or Microsoft SQL Server 2008 and at least one customer that is running Oracle Server 9i, 10g, or 11g. All three customers MUST be using the SAME VERSION AND MODEL SOFTWARE. A system that has been installed with only a single relational database is not acceptable. These databases, through ODBC, shall be true client/server, high performance, and ANSI standard capable of handling high transaction rates and multiple users concurrently accessing and modifying the database. The SYSTEM shall store dates and times in UTC time. 1. Preservation of Data Integrity The SYSTEMs RDBMS shall preserve data integrity in the following ways: a) Transaction Processing Transaction processing guarantees the consistency and recoverability of the RDBMS. Transaction processing shall assure that all transactions are performed as a single unit of work, even in the presence of a hardware or general SYSTEM failure. b) Enforced Data Integrity The SYSTEMs RDBMS shall enforce data integrity within the database itself, guaranteeing that complex business policies shall be followed. Referential Integrity maintains consistency between multiple tables of a database. For example, you do not want to delete an access level from the database without removing that access level from all cardholders that are assigned the access level. The SYSTEMs RDBMS shall use advanced data integrity features such as data types, defaults, and rules to enforce data integrity. Stored procedures and triggers shall also be used to insure the integrity and security of data. c) User-Defined Data Types The SYSTEMs RDBMS shall utilize data types, which provide the simplest form of data integrity by restricting what kinds of information (for example: characters, numbers, or dates) may be stored in the columns of the database tables. d) Encrypted User Defined Fields The SYSTEM shall allow the encryption of user defined fields in the database. The SYSTEM shall decrypt and display the data in the client application. The SYSTEM shall leave the data encrypted in the database.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 17

SECTION I
d) Defaults

SYSTEM ARCHITECTURE

The SYSTEMs RDBMS shall also utilize Defaults, which allow the SYSTEM to specify a value that the RDBMS inserts if no explicit field value is entered. e) Rules The SYSTEMs RDBMS shall enforce rules, which are integrity constraints that go beyond those implied by a fields data type. Whenever a user enters a value, the RDBMS shall check the value against any rule that has been created for the specified field. For example, rules can require that a value fall within a particular range, match a particular pattern, or match one of the entries in a specified list. The SYSTEMs RDBMS shall also provide two powerful and flexible features for enforcing programming integrity and business rule logic centrally at the server: stored procedures and triggers. 1) Stored Procedures The RDBMS shall incorporate stored procedures for increased data integrity. For example, whenever a SQL command is sent to the RDBMS for processing, the server shall parse the command, check its syntax to see if it makes sense, check to see if the requester has the permissions necessary to execute the command, and formulate an execution plan to process the request. 2) Triggers Triggers are a special type of stored procedure. Triggers are associated with particular pieces of data and are automatically initiated whenever attempts to modify that data are made. 2. Mature Client/Server Architecture The SYSTEM shall support a two tier mature client/server architecture in which the central database server performs all of the data processing. The clients shall be one of many types of client workstations including administrative, alarm monitoring, access control, asset management, digital video management, visitor management, intrusion detection management, or enrollment & badging client workstations. The client workstation shall send all requests to the database server, which does all of the processing. The database server then sends only the results of the request back to the client workstation. This minimizes network traffic and ensures data integrity as a central database is performing all processing. 3. N-tier architecture The SYSTEM shall support the use of N-tier architecture for some applications. Applications that support N-tier architecture will be specifically described as such. The SYSTEM shall support the expansion of the architecture (layers) so that the CUSTOMER can deploy the SYSTEM in a manner that meets their requirements and architecture. The LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 18

SECTION I

SYSTEM ARCHITECTURE

SYSTEM shall allow for, but not require, the separation of the database, application server, web server, and client interface. The SYSTEM shall require that all connections to the database are performed through a trusted link from the client or interface. 4. Advanced Thin Client Architecture The SYSTEM shall also provide an advanced thin client architecture. This architecture shall provide CUSTOMER with complete access to configure and operate their SYSTEM software through a simple web browser interface. The need for installed SYSTEM desktop client software shall not be required. The SYSTEM thin client architecture shall allow for the installation of web server software and, once the web server is configured, shall allow an unlimited number of client workstations (based on SYSTEM licensing connections) to attach to the server and run any of the SYSTEM applications. Virtually any desktop operating system that supports a web browser shall be able to utilize the SYSTEM thin client architecture. This shall include Windows 2008, Windows 2003, Windows 2000, Windows Vista, Macintosh, Unix, Solaris and Linux. The SYSTEM thin client architecture shall also support mobile computing environments, such as Windows CE. The interface shall display a minimum color depth of 8 bits (256 colors). The SYSTEM thin client architecture shall work in conjunction with Citrix Presentation Server 4.5 for Windows Server 2003. Such thin client architecture shall be achieved through Independent Computing Architecture (ICA) technology. Use of the Citrix Presentation Server 4.5 for Windows Server 2003 shall be in a one- or two-server configuration, allowing the SYSTEM to be deployed as three-tier applications. Each client workstation shall have an appropriate browser installed and shall consist of any combination of access control, system administration, asset management, alarm monitoring, digital video management, visitor management, or Credential Management functions. E. Network Design The SYSTEM shall be designed to allow it to work with any industry standard network protocol and topology listed below: 1. TCP/IP 2. Novell Netware (IPX/SPX) 3. Digital PATHWORKS 4. Banyan VINES 5. IBM LAN Server (NetBEUI) 6. IBM SNA Networks 7. Microsoft LAN Manager (NetBEUI)

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 19

SECTION I
8. NFS Networks

SYSTEM ARCHITECTURE

9. Remote Access Service (RAS) via ISDN, x.25, and standard phone lines There shall not be a limit to the number of client workstations that shall be attached to the database server. Each client workstation shall have the ability to consist of any combination of access control, system administration, asset management, alarm monitoring, digital video management, visitor management, intrusion detection management, or credential management functions. The SYSTEM shall be able to operate transparently in both a LAN and WAN environment, as long as one of the above protocols or network topologies are utilized. The SYSTEM shall be designed so that any Windows 2008/2003/XP/Vista based client workstation on the network that is licensed to operate the SYSTEM Software can have Intelligent System Controllers connected to them. This design shall save installation and wiring costs, as Intelligent System Controllers do not have to be home-run wired back to the database server. As such, any alarm in the SYSTEM, regardless of the Intelligent System Controller that generated the alarm, shall be routed to any client workstation on the network. Alarms shall also be routed to multiple client workstations on the network and shall have the ability to be routed to different client workstations during different hours of the day through time zone control. F. Graphical User Interface The SYSTEM shall have an easy to use Windows Graphical User Interface. It shall be intuitive and all messages and commands shall have the capability to support multiple languages. All functions shall be both keyboard and mouse driven. Within the alarm monitoring module of the SYSTEM, all major functions (such as acknowledging alarms, opening doors, and viewing cardholder information, etc.) MUST be accomplished in one or two mouse clicks. Any more than two mouse clicks is not acceptable. The SYSTEM shall have the ability to have SYSTEM information that shall be viewed in the application windows to be in a user defined typeface and point size. The SYSTEM shall support a minimum of 55 Fonts. These fonts shall be available from a pick list to the System Administrators. This shall be especially important in the alarm monitoring module of the software. The SYSTEM shall integrate toolbars that shall be movable and sizable as shortcuts to different forms within the SYSTEM. A Help icon shall be available in all modules of the software giving System Operators/System Administrators the ability to obtain on-line help with a single click of the mouse. The help command shall also be keyboard driven.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 20

SECTION I

SYSTEM ARCHITECTURE

The SYSTEM shall utilize a tabular format within the software to group procedures and forms together to guide the System Administrator through SYSTEM configuration. G. Migration & Upgrades The SYSTEM shall support a seamless upward and horizontal migration path from system to system. The SYSTEM shall ship to the customer with the ability to support the largest system in the product line complete with all the modules, features and functionality described above and below. The CUSTOMERs system size and feature set shall be controlled by a software/hardware license key and shall be programmed based on licensing. Upgrading from SYSTEM level to SYSTEM level shall be efficient, easy, and require only a change in the software/hardware license key code for the application portion of the SYSTEM. Adding new modules, activating features, increasing card reader capacity, and enabling additional functionality shall all be accomplished over the telephone without the vendor having to go to the CUSTOMER site. All systems shall be 100% upward compatible. Access control field hardware shall be compatible with all systems. Access control field hardware (Intelligent System Controllers, Input Control Modules, Card Readers, etc.) shall not have to be replaced or upgraded as the CUSTOMER migrates from one SYSTEM level to the next. Client workstations, cameras, printers, and data shall also be compatible from one SYSTEM level to the next. These devices shall not have to be replaced as the SYSTEM grows from small to large. The Graphical User Interface shall be IDENTICAL for all systems, regardless of the size, number of client workstations, or operating system that is being utilized. The SYSTEM shall be designed so that the average System Operator will not know that the SYSTEM was even upgraded or modified. This shall prevent the re-training of System Operators/System Administrators each time the SYSTEM migrates to the next level. H. Seamless Integration All SYSTEM application modules, features, and functions MUST be generated from a single source code set. The access control, alarm monitoring, asset management, digital video management, intrusion detection, remote access level management, and visitor management, and credential management modules of the software shall be created from this single source code set. There absolutely shall not be separate source code bases for different modules. Thus, a single manufacturer must develop all modules of software. All SYSTEM modules shall be seamlessly integrated to feature a single system, single code base, single graphical user interface, and single database. This shall allow for the ease of maintaining the SYSTEM and allow for the ease of future upgrades and enhancements. All SYSTEM features and functionality listed in the LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 21

SECTION I

SYSTEM ARCHITECTURE

proceeding pages shall ship with each system. Features and functionality available to CUSTOMER shall be determined through licensing and shall be controlled by a hardware/software license key. All SYSTEM data must reside in a single database on the network and must be instantly accessible from every/any client workstation connected to the network that is licensed to do so. This shall provide automatic change propagation to all client workstations on the SYSTEM as well as a common database to consolidate all information and allow for better disaster recovery. As such, any modifications made to cardholders, time zones, assets, or access levels shall be downloaded in real-time to all related Intelligent System Controllers.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 22

SECTION II
FUNCTIONAL & OPERATIONAL REQUIREMENTS

SECTION II

FUNCTIONAL REQUIREMENTS

Section II - FUNCTIONAL & OPERATIONAL REQUIREMENTS

A. General The design of the Total Security Knowledge Management Solution (SYSTEM) shall include devices and equipment to monitor and control access of cardholders, visitors, and assets to restricted areas, detect and deny unauthorized attempted entries within specific buildings or areas, annunciate alarms, record & store digital video, and generate reports. The SYSTEM shall also include devices and equipment to detect changes of state for alarm points such as motion detectors or dry contacts. Credential management and badging capabilities shall be seamlessly integrated so that the SYSTEM shall also be capable of generating and managing credentials for cardholders. Once incorporated with the daily operations of the designated facility, the SYSTEM shall detect and deny unauthorized entry into restricted areas, while granting entry to individuals who have proper access rights. The SYSTEM is to be designed and configured to provide operational flexibility, reliable performance, and ease of use. B. Customer Responsibilities CUSTOMER shall have the responsibility for configuring, managing, and operating the SYSTEM, as well as creating and maintaining the graphical representations of the designated facility for use in conjunction with the SYSTEMs Graphical Map Creation and Editing Module. C. Operational Concept The SYSTEM shall consist of equipment and devices placed at predetermined locations to ensure that only cardholders, visitors, and assets that are authorized to enter secured areas through certain doors or gates can do so. This shall be accomplished by means of a computer(s) and electronic devices used in conjunction with door locks, gate operators, card readers, and/or closed circuit television. When a new cardholder presents himself/herself to the Enrollment Operator or is changing job responsibilities and is in need of a new or replacement credential, a personnel form shall be available on the SYSTEM. This employee data screen shall contain at a minimum 20 data entry fields of information that will include, but not be limited to, the following: First Name Address Home Phone Last Name Birth Date Middle Initial Title Social Security Number Cardholder Number Badge Type Office Phone Department The employee data screen shall allow for a minimum of 32 pages each of cardholder, visitor, and visit information that shall be input upon enrollment. Above and beyond the LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 24

SECTION II

FUNCTIONAL REQUIREMENTS

fixed fields such as Last Name, First Name, Social Security #, there shall also be userdefinable fields which the SYSTEM can designate, if desired, as drop-down menus to ensure data integrity. These fields shall vary in character length as dictated by the System Administrator. Data fields shall be assigned as alphanumeric, numeric, date, or unique. Numeric, date, and unique fields shall be generated by the SYSTEM if desired. As a fundamental operation, the SYSTEM shall provide a seamlessly integrated link between the Credential Management and Access Control & Alarm Monitoring functionality. This shall allow specific information concerning cardholders to be automatically downloaded to all Intelligent System Controllers and to be shared by both the access control and credential management modules utilizing a single database, thus enabling the SYSTEM to grant or deny access to card reader controlled access points. This is to be provided under a single operating environment. After the applicant's picture is captured by the SYSTEM, the photo image is to be printed on a badge and appear in a pre-defined format. D. SYSTEM Capacities The SYSTEM shall support an unlimited number of card readers, input points, video cameras, intrusion detection points, and relay outputs. The SYSTEM database server shall support an unlimited number of cardholders, visitors, and assets limited only by the memory located in the Intelligent System Controllers in which cardholder information shall be downloaded. The database server shall also support an unlimited number of system events and System Operator transactions in the history file. The SYSTEM shall support an unlimited number of client workstations, so long as the network supports them. A fully loaded system shall guarantee a one half-second response time for access granted/denied decisions from the time that a cardholder swipes his/her badge. E. SYSTEM Features and Requirements All SYSTEM applications must be easy to use and visually attractive. The SYSTEM shall utilize a user friendly Windows Graphical User Interface. It shall utilize keyboard and mouse operations with graphical presentations of screen information. System Operators/System Administrators shall change the look and feel of the applications by setting the typeface and size of font for the way they wish for the SYSTEM information to be displayed. A minimum of 255 typeface combinations shall be available from which System Operators will choose. Each application shall provide a consistent user interface across all operations of the SYSTEM. All routine information displayed and requiring input must be in a language supported by the SYSTEM language pack. No operation must require the interpretation of machine code, the use of mnemonics, or the use of function keys.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 25

SECTION II Access Control

a) Time Zones

FUNCTIONAL REQUIREMENTS

The SYSTEM must be capable of creating and storing up to two hundred fifty five (255) time zones. Each time zone must have a minimum of six (6) intervals. Each interval shall be assignable to any day of the week and capable of being restricted on a minimum of eight (8) types of holidays. Time zones shall be assigned an alphanumeric name using up to 64 characters and shall act as templates to be applied to access levels, card reader modes, alarm inputs, alarm outputs, and alarm masking and logging functions. Time zones must be able to be added, modified, and deleted quickly by the System Administrator without vendor intervention. All time zones shall be downloaded to all related Intelligent System Controllers for distributed processing and local decisionmaking. b) Access Levels All cardholders shall have access based on facility, card reader, time, and day. For example, some badges must only allow access to the facility on weekdays between 9:00 a.m. and 6:00 p.m., while other badges shall allow access on weekends between 12:00 p.m. and 4:00 p.m. and so on. These time zones for each day are to be pre-defined by CUSTOMER and must be able to be modified quickly by the System Administrator without vendor intervention. The SYSTEM shall allow the System Administrator to define access levels which shall be assigned an alphanumeric name using up to 64 characters and which combine card readers and time zones. Card readers shall have the ability to be assigned to any or all access levels defined in the SYSTEM. As such, an access level can consist of any or all card readers in the SYSTEM. Time zones shall be allowed to belong to any or all access levels so that the time zone only has to be defined once. Access levels must be able to consist of multiple card reader assignments; each card reader shall be capable of having a distinct time zone assigned. The card readers must grant access to cardholders assigned to the appropriate access levels. The capability to define a minimum of 32,000 access levels is required to provide the System Administrator flexibility in assigning access privileges to cardholders. A minimum of thirty-two (32) access levels shall be assignable to each cardholder. Due to the above minimum requirements, the SYSTEM shall support a minimum of 10,000,000 access level combinations for assignment to the cardholders. The SYSTEM shall also allow an Allow User Commands option to be assigned on an access level by access level basis. All cardholders assigned an access level with the Allow User Commands option checked will have the ability to activate and utilize functions at card readers with keypads (that also have the Allow User Commands option checked) through use of the card readers keypad. Additionally, access levels shall have the option to be assigned first card unlock authority, meaning that cardholders with that access level assigned shall have the authority to place a card reader into an

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 26

SECTION II

FUNCTIONAL REQUIREMENTS

unlocked mode (based on them entering the area at the assigned card reader) after a predefined time of day based on that card readers settings. The SYSTEM shall allow for access level options. The System Administrator shall have the option to configure the SYSTEM to allow or disallow duplicate access levels. The System Administrator shall also have the option to configure the SYSTEM to allow or disallow empty access levels. c) Temporary Access Levels Inclusive of the above 32,000 Access Levels, the SYSTEM shall allow the System Administrator to define Temporary Access Levels that combine card readers and time zones. Card readers shall have the ability to be assigned to all temporary access levels and a temporary access level can consist of all card readers in the SYSTEM. Time zones shall be allowed to belong to any or all temporary access levels so that the time zone only has to be defined once. Temporary Access levels must be able to consist of multiple card reader assignments; each card reader shall be capable of having a distinct time zone assigned. Temporary Access Levels shall be assigned an alphanumeric name using up to 64 characters and shall allow System Administrators the ability to assign activation and deactivation dates and times to the access level, thus giving a date/time when the access level will become active and a date/time when the access level will no longer be valid. These temporary access levels shall then be assigned to cardholders for special occasions or visitor privileges, giving them temporary access to specific card readers. Temporary access levels shall be stored in the ISC such that they function properly in the event the ISC is off-line with the database server. d) Access Groups Access Groups shall be assigned an alphanumeric name using up to 64 characters and shall allow System Administrators to group access levels together for ease of assignment of access levels to cardholders. Access Groups allow System Operators to assign a single access group to a cardholder in the enrollment process instead of multiple access levels. Up to thirty-two (32) access levels shall be assignable per access group. The SYSTEM shall allow System Administrators to define an unlimited number of access groups. e) Precision Access Levels The SYSTEM shall include the ability to utilize Precision Access Levels above and beyond the aforementioned 32,000 standard and temporary access levels. This shall offer the ability to assign unlimited card reader/time zone combinations. 1) Inclusion Access Levels Inclusion Access Levels shall be assigned an alphanumeric name using up to 64 characters and shall offer the ability to assign unique inclusion access level groups (card reader/time zone combinations) for each individual cardholder, in addition LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 27

SECTION II

FUNCTIONAL REQUIREMENTS
to the cardholders thirty-two standard access levels. This shall give System Administrators the ability to assign as many card reader/time zone combinations as desired for each cardholder, thus removing the restriction of thirty-two access levels per cardholder.

f) Holidays The SYSTEM must allow the System Administrator to designate certain dates as holidays. As well, the dates for Daylight Saving Time shall be definable and shall automatically take effect without System Administrators/System Operators intervention. The SYSTEM shall support a minimum of 255 Holiday assignments. A cardholders access rights, card reader modes, and alarm masking schedules must be able to be altered when the current date is designated a Holiday. Holidays shall be assigned an alphanumeric name using up to 64 characters and shall be grouped into eight (8) types of holidays, and shall be assignable to individual time zones. The SYSTEM shall support Holiday Ranges that shall allow a single holiday to span across multiple calendar days. For example, Christmas may begin on December 24th and end on January 2nd and shall be defined as a single holiday. The SYSTEM shall support an embedded calendar in which System Administrators can select the Holiday dates. The calendar shall support a minimum of one hundred (100) years beyond the current date. This shall allow System Administrators to program holidays for upcoming years if desired, so long as they do not exceed more than 255 holidays in the SYSTEM at any one time. g) First Card Unlock The SYSTEM shall support a First Card Unlock feature. When configuring the default attributes of a card reader in System Administration, a first card unlock setting shall be selectable. First Card Unlock requires that a valid access grant shall be received at a card reader (by an authorized cardholder) after the time zone change has occurred before placing the reader into an unsecured mode. For example, a card reader in a lobby is programmed to unlock at 9:00 AM Monday through Friday. Each day after 9:00 AM, the card reader will await a valid access grant from an authorized cardholder before setting the mode to unlocked. An authorized cardholder is one that has the first card unlock authority configured as part of their access level. Thus, certain cardholders could enter the area after 9:00 AM and not cause the card reader to unlock due to their authority level. If a card reader currently has first card unlock enabled and its online mode is changed, then first card unlock shall be disabled. h) Database Segmentation The SYSTEM shall employ advanced database segmentation functionality. Each segment shall be allowed to have its own unique set of cardholders, hardware, and system LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 28

SECTION II

FUNCTIONAL REQUIREMENTS

parameters including access control field hardware, time zones, access levels, etc., which shall allow System Administrators to expand upon current hardware constraints. For example, each segment shall have its own 32,000 access levels, 255 time zones, and 255 holidays. As such, only credentials that are assigned access levels to card readers in a segment need to be downloaded to the Intelligent System Controllers in that segment. Cardholders shall be allowed to belong to one segment, many segments, or all segments. The SYSTEMs database segmentation functionality shall also provide a segment/landlord architecture to object records in the SYSTEM, where segment System Administrators and Operators can only view, add, modify, delete, and manipulate cardholders, system parameters and access control field hardware that belong to their respective segments. As such, Landlord Administrators shall have complete control over the entire system. System Administrators and System Operators shall be assigned the segments they are allowed to view and control. System Administrators and System Operators may be assigned to more than one segment and a segment may be assigned to more than one System Administrator and System Operator. A one-to-many relationship shall exist for System Administrators and System Operators with respect to segments. For example in a 10 segment system, a System Administrator or System Operator shall be able to belong to one, two, five, seven, or all ten segments. The SYSTEM shall support a minimum of 65,000 segments. System Administrators and System Operators shall also be assigned which pages of the Cardholder Form that they are able to view and edit. The following database objects shall be available for segmentation: Access Groups Access Levels Actions Action Groups Alarm Inputs Alarm Mask Groups Alarm Outputs Alarms Areas Badge Types Card Formats Cardholders Device Groups Digital Video Archive Server

Fire Panels Guard Tours Global I/O Function Lists Global I/O Links Holidays Intercom Panels Intercom Stations Intrusion Detection Panels ISCs

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 29

SECTION II
Maps Monitor Zones Personal Safety Panels Precision Access Groups Receiver Accounts Tour Groups

FUNCTIONAL REQUIREMENTS
Card Readers Central Station Receivers System Operators Time Zones Visitors User Permission Groups

i) Field Hardware Communications The SYSTEM shall communicate with the Intelligent System Controllers (ISC) by either RS-485 or RS-232 EIA standard. The SYSTEM shall have the ability to communicate with ISCs by LAN/WAN connections utilizing TCP/IP communications protocol. The SYSTEM shall also have the ability to communicate with the ISCs through remote dial up capabilities. The communication baud rate shall be SYSTEM selectable from 1,200 to 115,200 bits per second. The SYSTEM software shall take full advantage of its multi-tasking capabilities, allowing downloads of cardholder data and any ISC information to take place while monitoring and receiving alarms from the field hardware. Downloading database changes shall not interfere with any output control, access decisions, alarm monitoring, traces, or any other required function of the field hardware and alarm monitoring client workstation. Communications between the SYSTEM client workstation(s) and the ISC(s) shall be interleaving so that alarms will still report to their respective alarm monitoring client workstations while downloads are occurring. Upon losing and then restoring communications between the ISC and the SYSTEM database, database synchronization between the SYSTEM database and the local database in each ISC shall be fast and efficient. Every change made to the ISC database shall establish a time/date stamp for the change. When communications are restored, database synchronization shall occur immediately and without System Operator intervention. The time-date stamp shall be compared with any changes in the SYSTEM database, hardware configuration, events, or output control commands and the SYSTEM shall log which changes occurred after the off-line event. Any changes made to the SYSTEM database while the SYSTEM was off-line shall also be simultaneously downloaded to all ISC databases configured in the SYSTEM. j) Dual Path Field Hardware Communications The SYSTEM shall support dual path communications between the database server and the Intelligent System Controllers. This shall allow for two paths of communication: a primary and secondary path. The primary path shall communicate between the database server and the Intelligent System Controllers (ISC) by either RS-485 or RS-232 EIA standard, LAN/WAN connections utilizing TCP/IP communications protocol, or through remote dial up capabilities using modems. The secondary path shall communicate via RS-485 or RS-232 EIA standard (dial-up shall not be the primary connection using this LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 30

SECTION II

FUNCTIONAL REQUIREMENTS

method), LAN/WAN connections utilizing TCP/IP communications protocol or remote dial up capabilities using modems. Upon sensing a loss of communications via the primary communication path, the ISC shall automatically initiate the switching of communications to the secondary communications path. Once communications is switched from the primary path to the secondary path, the host shall periodically check and determine if the primary communications path has been restored. Upon restoration of the primary communications path, the host shall restore communications back to the primary communications path. Alarms shall be posted to alarm monitoring client workstations when the primary communications path is lost and/or restored. The currently active path shall be displayed with the Intelligent System Controller status in the System Hardware Status Tree. k) Multi-Drop Panel Support The SYSTEM shall support a multi-drop Intelligent System Controller architecture whereby up to eight (8) ISCs shall be multi-dropped on a single RS-485 communications line and whereby all eight panels communicate back to a single serial communications port. The multi-drop panel support shall be used in conjunction with other ISC wiring support such as the star wiring configuration, home-run wire architecture, and advanced distributed network architecture. l) Intelligent System Controller Remote Dial Up Support The SYSTEM shall support Remote Dial Up operations to and from the Intelligent System Controller (ISC). The dial up connection shall be either a constant connection or a scheduled connection. If the connection is constant, then every panel shall have its own modem at the host. If the connection is scheduled, then all panels using remote dial up shall have the ability to share the same host modem(s). System Administrators shall have the ability to define the modems available in the pool. For each modem, System Administrators shall be able to define the modem type and the client workstation that it is installed to. System Administrators shall have the ability to configure specific ISCs to receive selective cardholder downloads of access permissions for cardholders to either be on demand access or resident access permission or both. This ability shall allow a System Administrator to perform a database download, and depending on the ISCs configuration, either a full download of all cardholders or a selective download of specified access level shall occur. Dialup sessions shall occur under any of the user defined scenarios:
1.

On Demand Connection A System Operator shall have the ability to automatically initiate a dial in session to an ISC via the alarm monitoring module. LENEL - A UTC FIRE & SECURITY COMPANY

OnGuard

Functional Specifications Version 6.3 Series

Page 31

SECTION II
2.

FUNCTIONAL REQUIREMENTS
Scheduled Connection System Administrators shall have the ability to configure the SYSTEM so that the ISC dials into the SYSTEM at a pre-determined times through use of time zones. Critical Alarm Activated System Administrators shall have the ability to configure the SYSTEM so that the ISC initiates a dial up session with the SYSTEM when a critical alarm is activated in the field. Buffer Threshold System Administrators shall have the ability to configure the SYSTEM so that the ISC initiates a dial up session with the SYSTEM when a pre-determined number of events are stored in the ISC memory buffer.

3.

4.

m) SYSTEM to Intelligent System Controller Encryption Data security for encrypted connections between SYSTEM and Intelligent System Controllers shall be provided by the full implementation of the Federal Information Processing Standard, FIPS-197, utilizing the 128-bit Advanced Encryption Standard (AES), also known as Rijandael, a symmetric encryption algorithm. The 128-bit AES encryption MUST be certified by the National Institute of Standards and Technology (NIST). FIPS-197 supersedes the aging Data Encryption Standard (DES) defined in FIPS-46-3. Implementation of FIPS-197 shall solve the data security requirements for open network connections by providing a means to secure the data over the non-secure network by encryption. The Intelligent System Controllers shall also support a 32 bit issue code. This shall only be used when implementing a Physical Access Control Systems (PACS) low and medium security profile enhancement. n) Intelligent System Controller to Reader Interface and I/O Module Encryption Data security for encrypted connections between Intelligent System Controller and downstream modules (Reader interface and I/O Modules) shall be provided by utilizing the 128-bit Advanced Encryption Standard (AES), also known as Rijandael, a symmetric encryption algorithm. The encryption between the ISC and downstream modules must support use of a diversified session key derived from a shared secret master key algorithm. The shared secret master key must be settable to insure uniqueness, and to authenticate connected modules prior to activating them for the session. o) Area Control The SYSTEM shall provide five (5) area control features: Global Hard Anti-passback, Global Soft Anti-passback, Timed Anti-passback, Two Person Control, and Occupancy Limit. Area control shall be a security method of preventing a person from passing their badge to another person for dual entry into a single location utilizing one card. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 32

SECTION II
1) Global Hard Anti-passback

FUNCTIONAL REQUIREMENTS

The Global Hard Anti-passback feature shall require that a badge always be used to enter and exit an area. The controlled areas shall have both entry and exit card readers at all portals. Entry and Exit Readers shall be able to span across multiple ISCs. Areas shall be logically defined under the SYSTEM, and area control shall not be required at all areas of CUSTOMER facility to be utilized. Global Hard Anti-passback shall work in the following manner. A cardholder must present his/her badge at the entry card reader of the area that the person wishes to enter. Once access has been granted into the area, the cardholder cannot present the badge to another entry card reader within the same area without first presenting his/her badge to the respective exit card reader of that area. Should a cardholder attempt to use any other card reader in the same area besides the occupied areas exit card reader once access has been granted to that area, the cardholder shall be denied access and an alarm shall be reported to the alarm monitoring client workstation. Nested control areas (areas inside areas) shall be definable with a minimum of 64 entry and exit card readers. It shall be possible to have an area within an area and/or multiple areas that are independent of each other in which Global Hard Anti-passback rules shall apply. 2) Global Soft Anti-passback The Global Soft Anti-passback feature shall require that a badge be used to enter and exit an area. The controlled areas shall have both entry and exit card readers at all portals. Entry and Exit Readers shall be able to span across multiple ISCs. Areas shall be logically defined under the SYSTEM, and area control shall not be required at all areas of CUSTOMER facility to be utilized. Global Soft Antipassback shall work in the following manner. A cardholder must present his/her badge at the entry card reader of the area that the person wishes to enter. Once access has been granted into the area, the cardholder cannot present the badge to another entry card reader within the same area without first presenting his/her badge to the respective exit card reader of that area. Should a cardholder attempt to use any other card reader in the same area besides the occupied areas exit card reader once access has been granted to that area, the cardholder shall be allowed access (if that cardholder has the appropriate access level to access the new area), and an alarm shall be reported to the alarm monitoring client workstation. It shall be possible to have an area within an area and/or multiple areas that are independent of each other. The following summary criteria shall apply under Global Hard or Soft Antipassback: 1. Initially (Time 0) all card holders are reset to Area 0. 2. Any cardholder shall enter a controlled area anytime after Time 0 by presenting a badge to a SYSTEM entry card reader. 3. A cardholder shall not exit the controlled area unless he has entered the area presenting a badge to the SYSTEM entry card reader LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 33

SECTION II

FUNCTIONAL REQUIREMENTS
4. A cardholder shall not enter the controlled area a second time unless the cardholder has exited that area previously. 5. A cardholder shall be able to enter through any entry card reader and exit through any exit card reader of a single controlled area. 6. These options include a "forgiveness" feature that will allow the System Administrator to reset the anti-passback of all cardholders to Time 0 Area 0, either through a manual override or a time zone command. 7. The SYSTEM shall provide an anti-passback exempt option for privileged or VIP cardholders. Cardholders with this option will not have antipassback rules applied to them. 8. The SYSTEM shall also have a forgiveness feature that will allow the System Administrator to assign one free pass to an individual cardholder. This shall allow the System Administrator to reset the antipassback of an individual cardholder to Time 0 Area 0. 3) Timed Anti-passback Timed Anti-Passback shall allow the System Administrator to decide how long after a cardholder has swiped their badge that they will have to wait before the same badge will be accepted again at the same card reader. This helps prevent multiple swipes by an individual to allow access to others through turnstile doors. The SYSTEM shall also have a Timed Area Anti-Passback feature that shall provide all the functionality of Timed Anti-Passback but be enforceable across a group of readers. This option shall not be useable with the Global Anti-Passback feature. 4) Two Person Control Two Person Rule shall be provided to restrict access to certain areas unless there are two (2) cardholders present. This restricts individuals from being alone in restricted or highly secure areas. When an area is configured for Two Person Rule, the following criteria shall prevail: 1. The card reader shall grant access only if two valid cardholders (with authorized access levels) swipe their badges one after the other. In the event that a second authorized card is not presented within 10 seconds of the first authorized badge, the card reader shall reset and the first card will have to be swiped again. 2. Once 2 people occupy an area, individual access shall be granted. 3. Individual exit shall be permitted until an area is occupied by only 2 cardholders at which point the Two Person Rule applies for exit.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 34

SECTION II
5) Designated One-Person Control

FUNCTIONAL REQUIREMENTS

The SYSTEM shall allow for a special One-Person Mode. This mode shall require that a designated cardholder is present before anyone else is allowed to access a certain area. This restricts individuals from accessing a restricted or highly secure area when not accompanied by the designated cardholder. When an area is configured for One-Person Mode, the following criteria shall prevail: 1. The card reader shall grant access only if the designated cardholder (with authorized access level) swipes their badge. 2. Once the designated cardholder occupies an area, individual access shall be granted normally. 3. Individual exit shall be permitted until an area is occupied by only the designated cardholder, once the specific cardholder leaves, the area will again require the specific cardholder to be present before any other individual is allowed to gain access. 6) Designated Two Person Control The SYSTEM shall allow for a special 2-Person Rule to restrict access to certain areas unless there are two (2) cardholders present and they are designated a special Team Member distinction. This restricts individuals from being alone in restricted or highly secure areas as well as restricting the type of personnel allowed in a certain area. When an area is configured for the Designated Two Person Rule, the following criteria shall prevail: 1. The card reader shall grant access only if two valid cardholders (with authorized access levels and special Team Member distinction) swipe their badges one after the other. In the event that a second authorized card is not presented within 10 seconds of the first authorized badge, the card reader shall reset and the first card will have to be swiped again. 2. Once 2 people occupy an area, individual access shall only be granted to other cardholders who have been designated the Team Member special distinction. 3. A Second designation, Supervisor can be assigned to other cardholders. Cardholders with the Supervisor designation shall be announced by means of a contact closure then their card is presented at the entry reader of the restricted area. The occupants of the restricted area may then choose to grant access to the supervisor by closing an external contact connected to the reader interface module, which will in turn energize the door strike output. Closing this contact at any other time shall not open the door.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 35

SECTION II

FUNCTIONAL REQUIREMENTS
4. Individual exits shall be permitted until an area is occupied by only 2 cardholders with special Team Member distinction at which point the Designated Two Person Rule applies for exit. 7) Tail Gate Control The SYSTEM shall allow for a tailgate sensor mode. This shall be triggered when a person receives an access granted. Upon receiving an access granted, an output will be fired momentarily, duration must not exceed one (1) second. If two people are granted access, the output shall be fired twice momentarily, duration must not exceed one (1) second. The output shall be configured to auxiliary output one of the reader. 8) Occupancy Limit Occupancy Limit shall restrict the number of cardholders that shall be present in an area at any given time. The Occupancy Limit area shall be able to be defined by the System Administrator to limit up to 65,000 cardholders to be in that area at any given time. Once the occupancy limit has been reached, a cardholder must swipe out of the exit card reader before the next cardholder may enter. Each area for which Occupancy Limit is enabled shall be definable with up to 64 entry/exit card readers. Multiple Occupancy Limit Areas shall be definable.

o) Field Hardware Configuration All field hardware configuration windows shall be accessed from either the SYSTEM Icon Toolbar or from menu options in the menu bar within the SYSTEM configuration module of the software. When a field hardware device is configured, it shall appear in the graphical system overview tree and in all appropriate forms. Configuration of Intelligent System Controllers (ISCs), Input Control Modules (ICMs), Output Control Modules (OCM), and card readers shall be provided in a Windows format and shall include the following features: 1. A tab format to logically group information into a series of forms within an icon or menu option. This shall allow for ease of configuration. For example, all forms that relate to the configuration of card readers shall be grouped together in the Card reader icon. 2. Drop down lists to define features 3. Check boxes 4. Spinners 5. Browse Buttons for ease of locating client workstations 6. Sortable Lists 7. Graphical System Overview Tree controls for ease of navigation and use

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 36

SECTION II

FUNCTIONAL REQUIREMENTS

The SYSTEM shall have the ability for bulk add, modify, and delete privileges for ISCs and card readers to allow for the ease of addition and maintenance of these field hardware devices. The SYSTEM shall provide the ability to search large lists of devices for a string or substring in the device name. p) Mustering The SYSTEM shall support advanced Mustering functionality. The Mustering function shall provide an automatic capability for registering cardholders that are on site during an incident. Designated exit and entry card readers shall be used to enter and leave hazardous locations and safe locations. When an incident occurs, a Muster Report shall be generated that consists of a listing of all personnel that are within the hazardous locations as well as all personnel that have registered in a safe location. 1) Hazardous Locations A Hazardous Location shall be defined using entry and exit readers associated with the location. Hazardous Locations shall have both entry and exit card readers at all portals. Hazardous Locations shall require that a badge always be used to enter and exit the area. Entry and exit readers shall be able to span across multiple ISCs. The System shall support nested Hazardous Areas (areas within areas). 2) Safe Locations A Safe Location shall be defined using entry and exit readers associated with the location. Safe Locations shall have both entry and exit card readers at all portals. Safe Locations shall require that a badge always be used to enter and exit an area. Entry and exit readers shall be able to span across multiple ISCs. One or more Safe Locations shall be specified for a given Hazardous Location. 3) Muster Mode Operation A Muster Mode shall mean that an incident has occurred and an evacuation is required of one or more Hazardous Locations. A Hazardous Location shall enter into Muster Mode either automatically via an occurrence of a given hardware event transaction (such as an Alarm Input going active) or manually via a System Operator placing the Hazardous Location into Muster Mode. When a Hazardous Location goes into Muster Mode, all associated Alarm Monitoring Workstations shall be notified with a breakthrough notification and Muster Reporting shall begin. 4) Muster Reset A Muster Mode shall be reset by a manual operation that shall mark a given Hazardous Location as no longer in Muster Mode.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 37

SECTION II

FUNCTIONAL REQUIREMENTS
Depending on the configuration of the Hazardous Location, a Muster Reset shall logically move all personnel recorded in the Safe Locations into another area. This area shall typically be the Hazardous Location itself or the outside area in which the Hazardous Exit Readers lead. A Muster Reset shall optionally remove all Badges from all associated Safe Locations. 5) Manual Personnel Movement The SYSTEM shall allow for System Operators to move one badge, or all badges inside an area, from one area (Hazardous Location or Safe Location) to another. 6) Live Muster Mode Reporting Upon entering a Muster Mode, a Live Muster Mode Report shall be activated. The Live Muster Report shall be configurable to activate immediately upon entering into Muster Mode, after a specified time-period from Muster Mode activation, or after the number of personnel in the Hazardous Location reaches a given count. The Live Muster Report shall be configurable to automatically refresh over time and automatically end once the count of personnel in the Hazardous Location reaches zero. The On-Line Muster Status Reporting shall include a current total head count of personnel in the Hazardous Location as well as listing each individual cardholder. An on-line status indicator in Alarm Monitoring shall show the total number of Cardholders carded into a Hazardous Location and the total number of Cardholders carded into a Safe Location during a Muster Mode. An Alarm Monitoring Workstation that logs on after a Muster Mode has been initiated shall automatically be notified that a Muster Mode is in progress and shall begin displaying a Muster Report according to the reporting configuration. The Live Hazardous Location and Safe Location Reports shall have the ability to select a Cardholder in the report and bring up their related cardholder record. The Live Muster Report shall display the last location, based on card swipe at a card reader, of each cardholder. The Live Hazardous Location and Safe Location Reports shall display a summary head count total. The Live Hazardous Location and Safe Location Reports shall be able to be sent to a printer. If there are any Safe Locations associated with the Hazardous Location, the Live Muster Report shall include a split screen Safe Location Report consisting of a report on all associated Safe Locations.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 38

SECTION II
7) Alarm Monitoring

FUNCTIONAL REQUIREMENTS

Hazardous Locations and Safe Locations shall be placed on graphical maps as Area Icons. A System Operator shall be able to click onto these icons and either run the Hazardous Locations/Safe Location Report or launch the Live Muster/Safe Location Trace Window. A counter shall be located below the icon to show the total count of personnel in the Hazardous Location/Safe Location. Hazardous Locations and Safe Locations shall be placed on the System Hardware Status Tree as Area Icons. A System Operator shall be able to click onto these icons and either run the Hazardous Location/Safe Location Report or launch the Live Muster/Safe Location Trace Window. A counter shall be located next to the icon to show the total count of personnel in the Hazardous Location/Safe Location. q) Alarm Masking Groups The SYSTEM shall support a group alarm masking feature whereas System Administrators shall be able to create groups of alarm inputs that enable them to mask or unmask multiple Input Control Module inputs and card reader inputs simultaneously. The following events shall have the ability to be part of an alarm masking group: 1. Input Control Module Events (a) Alarm Input Active 2. Card Reader Events (a) Auxiliary Input Active (b) Denied Count Exceeded (c) Door Contact Tamper (d) Door Forced Open (e) Door Held Open (f) Card Reader Input Tamper Alarm Masking Groups shall be able to be masked as a group or as individual points. System Administrators shall have the ability to specify the maximum number of alarms that shall be individually masked at any one time within an Alarm Masking Group. For example: There is a bank vault with 5 motion detectors that are grouped in an Alarm Mask Group called Vault Detectors. Masking the Vault Detectors group (so that a guard may enter the room) shall mask all motion detectors. However, when masking motion detectors individually (e.g. because they are malfunctioning), a guard is only allowed to

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 39

SECTION II

FUNCTIONAL REQUIREMENTS

mask up to 2 motion detectors. Attempting to mask a third motion detector in the group shall be prevented. Alarm Masking Groups must support the ability to be masked multiple times. For example, when a mask group is initially created it has a mask count of zero (0). The count increments each time that the group is masked. If the group is masked two (2) times, it needs to be unmasked two (2) times for the alarms to begin reporting. The SYSTEM must also support Supervisor (System Administrator) override to reduce the alarm masking group count to zero with one command. Alarm Masking Groups shall be able to be masked and/or unmasked via alarm monitoring commands by guards, via card reader keypad function keys, or via global linkage commands. The SYSTEM shall support 2-Man Control for masking Alarm Masking Groups whereby two guards at 2 different locations are required in order to mask an Alarm Masking Group. The SYSTEM shall support an Alarm Masking Group status change (Masked to Unmasked or Unmasked to Masked) action to be linked to a function list that is capable of performing many system actions, such as activating a relay output. For example, when an Alarm Mask Group is unmasked, an LED by a door will not be illuminated. However, when the Alarm Mask Group is masked (either by PIN Code/Card reader functionality or by a System Operator in Alarm Monitoring), the LED by the door will illuminate. The SYSTEM shall support a minimum of 64 Alarm Masking Groups per Intelligent System Controller with a minimum of 200 alarm inputs per Alarm Masking Group. r) Global Input/Output/Event Linkage The SYSTEM shall support a global linkage feature whereby any input/output/event shall be linked to any other input/output/event in the SYSTEM. Input/Output Linkages shall be able to span across Intelligent System Controllers. System Administrators shall be able to create global I/O function lists, each consisting of a sequence of actions to be performed, such as changing card reader modes, activating outputs, and opening or closing anti-passback areas. Each function list may include up to six actions. System Administrators shall then be able to link events to the aforementioned global I/O function lists such that a particular device change will execute a function. The SYSTEM shall allow for the creation of correlation logic to execute a function only when two or more events occur within a specified time window. This correlation logic shall support both mandatory correlation of ALL members of a user specified a set of inputs (AND), and correlation of ANY members of a user specified set of inputs (OR). This correlation function must accommodate events that occur in close proximity but not necessarily overlapping. Simple Boolean logic does not satisfy this requirement. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 40

SECTION II

FUNCTIONAL REQUIREMENTS

Inputs shall include ANY System Event, including but not be limited to: 1. From the Database Server or Client PC (a) Communication loss 2. From the Intelligent System Controller (a) Cabinet tamper (b) Power failure 3. From the Input Control Module (a) Communication loss (b) Cabinet tamper (c) Power failure (d) Input points 4. From the Card Reader (a) Access activity from any cardholder (b) Access activity of a specific cardholder (c) Invalid access activity of any cardholder (d) Invalid access activity of a specific cardholder (e) Auxiliary inputs active (f) Cabinet tamper (g) Communication loss (h) Door contact tamper (i) Door forced open (j) Door held open (k) Power failure (l) Card reader tamper 5. From the Intrusion Detection Panel (a) Communication loss (b) Intrusion activity (c) Access activity Additional filters shall be applied so that a System Event Input can be filtered to a specific hardware device AND/OR a specific cardholder Badge ID.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 41

SECTION II

FUNCTIONAL REQUIREMENTS

When spanning ISCs, a timer shall be included to specify how long an input active will attempt to trigger its associated output in the event the output resides on an ISC that is temporarily off-line. Actions that are able to be a part of a function list shall include, but not be limited to: 1. Activating an Output Control Module Output 2. Activate a Card reader Auxiliary Output 3. Mask an Alarm Masking Group 4. Unmask an Alarm Masking Group 5. Open an Area 6. Close an Area 7. Chain to another function list 8. Log the function execution to the database 9. Set the active mode of a card reader 10. Test for Active Alarms in an Alarm group 11. Activate an Action Group 12. Activate a Time zone 13. Deactivate a Time zone 14. ISC Dial Back to the Host 15. Test Alarms within a Device Group 16. Activate Muster Mode 17. Print a Report Other Events that shall be used to trigger function lists shall include, but not be limited to: 1. Acknowledging an alarm Multiple function lists shall be linked to an alarm acknowledgment regardless of the ISC that the alarm was generated from 2. Minimum area occupancy 3. Maximum area occupancy 4. Host Communication Loss 5. Card Reader Keypad Commands and Function Keys 6. Performing a direct command from alarm monitoring

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 42

SECTION II

FUNCTIONAL REQUIREMENTS

For each function list that is linked to an input, event, or other function, System Administrators shall have the ability to state how the function will behave based on the current state of the input devices. Input events have several states (depending on the event type), each of which shall be programmed to affect a function lists state variable in a different way. These states shall be as follows: 1. Setting a logic term of its state variable to TRUE. 2. Setting a logic term of its state variable to FALSE. 3. Pulsing the function list. The devices and their types of inputs that shall be linked to a function list, along with their possible states are: 1) For Intelligent System Controller Events:

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 43

SECTION II
INPUT EVENTS Cabinet Tamper, Power Failure

FUNCTIONAL REQUIREMENTS
POSSIBLE STATES Not Configured, Secure, Fault, Alarm

2) For Card Reader Events:

INPUT EVENTS Communication Status Cabinet Tamper, Power Failure, Reader Tamper, Forced Open, Held Open, Door Contact Tamper, Aux Input 1, Aux Input2 Access Activity POSSIBLE STATES Not Configured, On-line, Off-line Not Configured, Secure, Fault, Alarm

Access Granted, Access Denied, Duress

3) For Input Control Module Events:

INPUT EVENTS Communication Status Alarms: Cabinet Tamper, Power Failure, Alarm Inputs (1-16) POSSIBLE STATES Not Configured, On-line, Off-line Not Configured, Secure, Fault, Alarm

4) For Host Computer Events:

INPUT EVENTS Communication Status POSSIBLE STATES Not Configured, On-line, Off-line

Any and each of the possible states for the above events shall be configured to set to perform one of the operations (Set TRUE, Set FALSE, Pulse) on an Output Variable logic term. An input/event may trigger multiple function lists and a function list shall have the ability to be triggered by multiple inputs/events. The SYSTEM shall support a minimum of 100 function lists per Intelligent System Controller each with a minimum of six actions per function list. s) Cardholder Escort Control The SYSTEM shall support advanced cardholder Escort functionality in conjunction with credential holder access levels. In addition, the SYSTEMs access levels shall support activation/deactivation dates. When a cardholder is given an access level with Escorted Cardholder privileges, the cardholder shall require an Escort to gain access to areas in which they are to have escorted access. The access level shall only be valid in the system during its activation and deactivation interval.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 44

SECTION II
An access level shall be set as:

FUNCTIONAL REQUIREMENTS

a. Not an escort and does not require an escort b. An escort c. Requires an escort A cardholder shall receive a specific type of access to an area depending on the access level they are assigned. For some areas, a cardholder may be an escort and in others they may be need to be escorted, depending on their access level. The Escort functionality shall work as follows: 1. Initially, if a card is read that does not require an escort (and has access), the door shall open. 2. If a card is read (and has access) that requires an Escort, the door will not open but instead the escorted cardholder will be placed in a queue and a timeout of 15 seconds shall begin. 3. If the reader supports an LED, the message Next Badge shall be displayed. 4. Before the timeout is reached, if another card is read that is not an escort, the door will not open, but the cardholder is queued and the timeout is restarted. This includes both escorted and normal cardholders. 5. This cycle shall continue until either the timeout is reached or an escort cardholders card is read. 6. If the timeout is reached, the access denied buzzer, LED (if exists), and text patterns are executed at the reader. In addition, a special access denied alarm shall be sent from the ISC for each cardholder in the queue. 7. Once an escort cardholders card is read, the door opens and each of the queued escorted cardholders in the queue, normal cardholders in the queue, and escort enter. In addition, an access granted event is sent from the ISC for each of the queued cardholders. t) Cardholder Use Limits The SYSTEM shall support a Cardholder Use Limit feature that shall allow System Administrators to specify the maximum number of times that a cardholder may use his or her credential at card readers in the SYSTEM. The SYSTEM shall allow for System Administrators to modify the number of uses a specific badge has left. This modification shall occur immediately to reflect the new use limit assigned.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 45

SECTION II

FUNCTIONAL REQUIREMENTS

The System Administrator shall have the ability to not allow a badge holder access to any readers that enforce the use limit. A System Administrator shall also have the ability to grant someone unlimited number of uses to readers that enforce the use limit. Any card reader in the SYSTEM shall have the ability to have the Cardholder Use Limit enforced. Assignment for use limits shall be on a cardholder by cardholder basis. Thus, cardholder A may have unlimited access to Card Reader 1, but cardholder B may only be able to access Card Reader 1 five times. As such, Cardholder A may only have access to Card Reader 2 nine times while Cardholder B has unlimited access to Card Reader 2. Every intelligent system controller (ISC) shall be able to keep track of each badges current uses left. These updates shall be provided to the database as badge transactions that are grants with entry are reported to the ISC. A cardholder shall have the ability to be given a maximum of 2,000,000 days of usage at card readers that have the cardholder use limit option enforced. u) Extended Individual Strike Times The SYSTEM shall support Extended Individual Strike Times that allows a card readers strike to be active for an extended period of time beyond the pre-determined standard strike time on a per cardholder basis. The extended strike time shall be user definable up to 255 seconds. Extended strike times shall be set on a card reader by card reader basis. System Administrators shall have the ability to determine which cardholders are granted the extended strike times. For example when Cardholder A swipes his card, the card reader strike shall be active for five (5) seconds, but when Cardholder B swipes his card, the strike shall be active for sixty (60) seconds. v) Extended Individual Door Held Open Times The SYSTEM shall support Extended Individual Door Held Open Times that allows a card readers door to be held open for an extended period of time beyond the predetermined standard held open time on a per cardholder basis. The extended held open time shall be user definable up to 131,070 seconds. Extended held open times shall be set on a card reader by card reader basis. System Administrators shall have the ability to determine which cardholders are granted the extended held open times. For example when Cardholder A swipes his card, the card reader door shall be allowed to be held open for five (5) seconds, but when Cardholder B swipes his card, the door shall be allowed to be held open for sixty (60) seconds.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 46

SECTION II

FUNCTIONAL REQUIREMENTS

w) Extended, on Demand, Door Held Open Times The SYSTEM shall support extended, on demand, door held times via a command keypad. The Extended Held Open command configuration shall consist of a command key sequence that shall be from 3 to 6 keys used to enter the number of minutes to extend the door held open time (up to 999 minutes) and a pre alarm time (from 0 to 30 minutes). Only those cardholders having Command Authority at a given card reader configured for Allow User Commands shall have the ability to execute the Extended Held Open command at that card reader. The Extended Held Open command shall be available after a valid cardholder has received an Access Grant at the card reader. The cardholder shall have a period of fifteen seconds after the Access Grant to enter the extended held open command sequence. If the command is accepted, the card reader shall be considered to be in extended held open mode. The extended held open time shall apply for a single door cycle. When the door is closed, the standard held open time shall again be used at that door for subsequent door cycles. If the cardholder entry for number of minutes does not fall within the defined range, the command shall be rejected and feedback shall be given consisting of an access denied buzzer pattern at the card reader and an appropriate text display at the LCD reader. At an LCD Command Reader currently in extended held mode, the time remaining until the extended door held open time expires shall be displayed. When a cardholder enters an accepted Extended Held Open command at a card reader, a transaction indicating the cardholder initiated the command shall be reported and stored in the SYSTEM audit trail. It shall include the number of minutes entered with the command. x) Guard Tour The SYSTEM shall support advanced Guard Tour functionality. A tour shall consist of one or more checkpoints defined as card readers or alarm inputs that a guard shall check during a guard tour. 1) Tours Each tour shall be assigned a name of up to 128 characters and subsequently assigned to one or more Alarm Monitoring Workstations that indicate from where automatic tours are to be launched. Each tour shall consist of a series of checkpoints that shall include card readers and/or alarm inputs. Tour checkpoints shall be ordered in the sequence within which they are to be visited. Tour checkpoints shall be assigned minimum and maximum times within which to be reached. A Tour Beginning Checkpoint

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 47

SECTION II

FUNCTIONAL REQUIREMENTS
shall also be defined to be linked with output actions. Checkpoints shall be able to be placed onto a graphical map. A tour shall additionally be linked to live video. Instruction text shall be assigned to a tour. These instructions shall be viewed and printed prior to launching the tour from an Alarm Monitoring Workstation. One or more output actions shall optionally be associated with a checkpoint event or a Tour Beginning Event. Actions shall include:
1. 2. 3. 4. 5. 6. 7.

Activating/Deactivating Outputs Masking/Unmasking Inputs Changing Reader Modes Executing Function Lists Opening/Closing Areas Sending Email Issuing a Page

One or more input masks shall optionally be associated with a checkpoint event. If a checkpoint event has been associated with an input mask or an output, a timer shall be configured (in seconds). Once that timer expires, the input mask or output shall be restored to its default state. The following checkpoint events shall be available to link to:
1. 2. 3. 4.

Checkpoint Reached on Time Checkpoint Reached Early Checkpoint Overdue Checkpoint Reached Late

2) Tour Groups Tour groups shall be created and assigned a name of up to 128 characters. Tour groups will consist of zero or more tours, listed by name. 3) Security Clearance Levels Security clearance levels shall optionally be created and assigned a name. Security clearance levels shall be assigned to one or more guard tours. A Security Clearance Level is a means of limiting the number of tour guards when a tour is launched. Particular Security Clearance Levels shall be assigned only to guards who will need access where the tour will take them. When a tour is launched, only those guards with the security clearance levels shall be listed.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 48

SECTION II
4) Guards

FUNCTIONAL REQUIREMENTS

Guards shall be selected from the general cardholder population. Guards shall optionally be assigned one or more security clearance levels. Guards shall be associated with one or more monitoring zones. 5) Scheduling Tours shall be optionally scheduled. When scheduling a guard tour, a single tour shall be scheduled for a specific time or recurring time. When scheduling a guard tour, a list of tours and tour groups may be associated with a specific time for random selection. Tours shall be assigned a notification value in minutes. When a given tour is scheduled for automatic launch, this value shall represent the amount of notice the System Operator is given before the tour is to begin. 6) Tour List All available tours and tour groups shall be listed within the System Hardware Tree inside of the System Administration module. Tour groups shall be expanded to reveal all tour members. 7) Tour Launching A tour shall be manually launched or launched based on a pre-defined schedule. For a scheduled tour, the Alarm Monitoring Workstations assigned to that tour shall display a notification X minutes (where X is defined by the System Administrator) prior to the scheduled time. The SYSTEM shall allow the System Operator to manually enter a Badge ID rather than selecting a guard from the list. Upon launching of the tour, a Guard Tour Live Tracking view shall automatically open. 8) Guard Tour Live Tracking The Guard Tour Live Tracking Window shall be opened automatically at the initiating monitoring station whenever a tour is launched. The Guard Tour Live Tracking Window shall consist of a series of columns including:
1. 2. 3. 4. 5. 6.

Checkpoint Sequence Number Checkpoint Name Checkpoint Status Checkpoint Min Time Checkpoint Max Time Checkpoint Time (0 if status is not reached or missed) LENEL - A UTC FIRE & SECURITY COMPANY

OnGuard

Functional Specifications Version 6.3 Series

Page 49

SECTION II

FUNCTIONAL REQUIREMENTS
The following checkpoint statuses shall be supported:
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

Checkpoint Not Reached Checkpoint Reached On Time Checkpoint Reached Early Checkpoint Overdue Checkpoint Reached Late Checkpoint Out of Sequence Checkpoint Missed Guard Tour Initiated Guard Tour Completed Guard Tour Completed With Errors Guard Tour Cancelled Guard Tour Terminated

9) Random Tours The SYSTEM shall support random tours. 10) Guard Tour Live Video Multiple live camera views shall be displayed simultaneously in a sliding window format. The next checkpoint to be hit shall be highlighted within the video matrix. The matrix shall include a number of cameras before and after that checkpoint. y) Elevator Control The SYSTEM shall provide elevator control using standard access control field hardware that will permit the restriction of cardholder access to certain floors while also allowing general access to other floors. The elevator control feature shall allow, at the elevator, the use of any card reader and all card reader modes used on any other card reader in the SYSTEM. For example, the card reader mode shall be time zone controlled to allow visitor access during business hours, and create higher security levels after working hours. An elevator card reader shall be located in the cab of the elevator. Each elevator card reader shall control access for a minimum of 128 floors. The card reader shall integrate to the standard Input Control and Output Control Modules and restrict which floor select buttons are accessible when a badge is swiped based on the cardholders access level. A single card swipe shall permit only one authorized floor to be selected. A request for another restricted floor shall require a second card swipe. Those floors programmed as public access (i.e. lobby) shall not require a swipe and shall be selected by any passenger.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 50

SECTION II

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support a separate Day Mode for each floor to allow visitor/general access to different floors during different times of the day. The SYSTEM shall also have the option of assigning a single time zone to all floors for a particular access level for ease of configuration. Elevator access levels shall be assignable to regular access levels for ease of assignment. A summary screen shall be provided for review of access level configurations. The SYSTEM shall be able to track which floor was selected by an individual cardholder for auditing and reporting purposes. System Operators shall be able to have control of each floor controlled by an elevator in the Alarm Monitoring Module. The SYSTEM shall have the ability for a System Operator to individually control any floor that is controlled by the elevator card reader. For example, a System Operator can select to send the elevator cab to floor 4 from the alarm monitoring client workstation. The SYSTEM shall have the ability to assign user friendly names to each of the floors being controlled by the elevator card reader. z) Graphical System Overview Tree A graphical system overview tree shall be available to depict a graphical representation of all field hardware (including ISCs, fire panels, intrusion detection devices, personal safety devices, intercom systems, central station alarm receivers), digital video hardware, access levels, time zones, access groups, holidays, and card formats that have been configured in the SYSTEM. If System Administrators wish to modify a device that is depicted on the graphical system overview tree or see its properties, they shall be able to double click on the icon and the SYSTEM shall bring them to the appropriate form. aa) Pre-Alarm The SYSTEM shall support a pre-alarm at the card readers in the field. The pre-alarm will sound a tone at the card reader after a valid access has been granted, the door contact opened, AND if the door remains open for a pre-defined period of time. This shall act as a reminder for the cardholder to close the door at the card reader. The card reader shall be able to be configured so that a pre-alarm warning starts providing an audible beep at a predefined time before an alarm state is triggered. This predefined time shall be definable by the System Administrator. Should the door not be closed within a System Administrator defined time after the pre-alarm sounds (up to 131,070 seconds), and a pre alarm warning sounds, a door held open alarm shall be generated and sent to the appropriate alarm monitoring client workstations. The held open time shall be configurable up to 131,070 seconds and have the capability to be different for different card readers. For example, the front door may be able to be held open for up to sixty (60) seconds, while the research lab door may only be able to be held open for fifteen (15) seconds.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 51

SECTION II
bb) Alarm/Event Logging

FUNCTIONAL REQUIREMENTS

All alarms and events in the SYSTEM shall by default log to the database that shall be used for reporting and back-up capabilities. However, the SYSTEM shall give System Administrators the ability to select on a time zone basis, the times that they require the SYSTEM to log specific events to the database. For example, in non secure areas, System Administrators may not want to log access grants for a particular card reader in the database during normal working hours, but want to know who accessed the area after hours. Alarm/Events shall be set to log or not log particular alarms/events on an individual card reader by card reader and input by input basis. cc) Scheduling Utility The SYSTEM shall support an advanced Scheduling Utility. The Scheduling Utility shall allow System Administrators to schedule actions to occur on a one-time or a recurring basis. Recurring schedules shall be configured to begin immediately, last indefinitely, or have optional start and end dates. The Scheduling Utility shall be available from both the System Administration and Alarm Monitoring modules. 1) Scheduled Actions The types of actions that shall be schedulable include but are not limited to:
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.

Action Group Event Archiving/Purging Arm/Disarm Area Start of Guard Tour Execution of DataExchange Scripts Activate, Deactivate, Pulse Device Output Activate, Deactivate, Pulse Device Output Group Global Anti-Passback Reset Download Firmware to ISCs Download Firmware to Lenel Network Video Recorders Download Firmware to IP Cameras Download Database to ISCs Execute Function List Mask/Unmask Inputs Mask/Unmask Input Groups Mask/Unmask Alarm Mask Group LENEL - A UTC FIRE & SECURITY COMPANY

OnGuard

Functional Specifications Version 6.3 Series

Page 52

SECTION II
17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29.

FUNCTIONAL REQUIREMENTS
Mask/Unmask Door Forced Opens Mask/Unmask Door Forced Opens for Reader Group Mask/Unmask Door Held Opens Mask/Unmask Door Held Opens for Reader Group Open Door Open Door Group Change Reader Mode Automatic Reports Reset Use Limit Move Bulk Badges From Area Deactivate Badges Logout Visitors Schedule PTZ preset

The Scheduling Utility shall provide a flexible scheduling mechanism to satisfy a wide range of scheduling needs, such as:
1. 2. 3. 4.

Every day, on the hour Every Monday at 8:00 am The first Sunday of every month The last Friday of every three months

2) One Time Execution The Scheduling Utility shall allow the System Administrator to configure an action to occur one time, on a given date and time. 3) Recurring Schedule The scheduling utility shall allow the System Administrator to configure an action to be performed many times over a period of time or indefinitely. 4) Frequency The Scheduling Utility shall allow events to be scheduled. This shall include:
1. 2.

Daily: Every n day(s). Weekly: Every n week(s). Furthermore, the System Administrator shall choose which day(s) during the week to perform the action. For example, every Monday, or every Monday, Wednesday and Friday. Monthly: This shall provide two options: LENEL - A UTC FIRE & SECURITY COMPANY

3.

OnGuard

Functional Specifications Version 6.3 Series

Page 53

SECTION II

FUNCTIONAL REQUIREMENTS
a. Day n of every m month(s). For example, Day 1 of every 3 months. b. The nth (day of the week) of every m month(s). For example: The 1st Sunday of every 1 month. 5) Daily Frequency On each day that the action is performed as per the frequency, the System Administrator shall also be able to specify the number of times the action is performed on that day. The options shall be:
1. 2.

Once, at a given time. Every n hours or minutes. For this option, the System Administrator shall specify, starting at and ending at times, which default to 12:00 AM 11:59 PM.

6) Schedule Duration For a recurring task, the System Administrator shall be able to specify the date range for which the schedule is valid:
1. 2.

Start date (defaults to current date). Either No end date (indefinitely) or a specific end date.

7) Run Once Now, Then Resume Schedule For recurring actions, the Scheduling Utility shall provide a mechanism to perform an action once immediately, then resume its normal schedule. 8) Monitoring the Scheduling Utility The Scheduling Utility shall provide means for the System Administrator to monitor its activities and the status of scheduled tasks. The information available shall include:
1. 2. 3. 4. 5. 6.

Next Start Date/Time Last Start Date/Time Last End Date/Time Last Run Duration (calculated from start and end times). Last Run Status (e.g. Successful, Error) Current status (e.g. Started, Paused, Stopped)

9) History Logging The Scheduling Utility shall maintain a history log in the database for actions that it executes.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 54

SECTION II
dd) Multiple Card Formats

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support an unlimited number of card formats. Magnetic stripe and Wiegand card formats shall be supported. Each ISC shall support a minimum of eight (8) access control card formats and if applicable, eight (8) asset formats. As such, each card reader shall also be able to support a minimum of eight (8) access control card formats. If applicable, asset readers shall be able to support a minimum of eight (8) access control card formats and eight (8) asset management card formats. The SYSTEM shall support any magnetic stripe format that uses card number, facility code, and issue code combinations with a maximum of a nine digit card number and two digit issue code. The SYSTEM shall support any industry standard Wiegand card format. ee) Card Reader Cipher Mode The SYSTEM shall support a card reader Cipher Mode that shall allow authorized cardholders to enter their Badge ID by typing it into a card reader keypad, thus emulating the presentation of the credential to the card reader. When a card reader is configured for cipher mode, an access attempt made by entering *<badge number># at the keypad shall be accepted as a magnetic card read. The number of keys pressed shall be consistent with the length of one of the assigned magnetic card formats. An access attempt made by entering *<number># at the keypad where the number of keys pressed is not consistent with the length of any of the assigned magnetic formats shall report an event transaction and deny access to the card reader. When cipher mode is configured for a given card reader, it shall remain in effect for any reader mode changes that are made other than facility code mode. ff) Denied Access Attempts Counter The SYSTEM shall support a denied access attempts count on a per card reader basis. The Denied Attempts Count value shall be configurable from 0 to 255. The following access denial types shall cause the current denied count to be incremented:
1. 2. 3.

Unknown PIN entry at a card reader configured as PIN or Card mode Invalid cipher entry at a card reader in Cipher Mode Invalid PIN entered for a given card at a card reader configured as Card and PIN mode Non-matching biometric presented for a given card at a card reader in biometric verify mode.

4.

The following events shall cause the counter to rest to zero:

1. 2.

10 minutes pass without any of the above denial types An access grant at the given card reader LENEL - A UTC FIRE & SECURITY COMPANY

OnGuard

Functional Specifications Version 6.3 Series

Page 55

SECTION II

FUNCTIONAL REQUIREMENTS

When the current denied count reaches the Denied Attempts Count configured for the card reader, a Deny Count Exceeded transaction shall be reported. This transaction shall only be reported when the limit is initially reached. It shall not report on subsequent denials. Through Global I/O functionality, the System Administrator shall be able to configure a Function List to execute when the Deny Count Exceeded transaction occurs for a given card reader, such as locking down the card reader or annunciating a local siren. gg) Card Reader Time Zone Overrides

The SYSTEM shall allow for the pre-defined default card reader settings to be overridden or temporarily changed on a time zone basis. At the beginning of the a selected time zone, the selected card readers operational mode shall be modified from its default mode to any one of the following modes: locked, unlocked, facility code, card only, card or PIN, card and PIN, card and Biometric, card or PIN and biometric, and/or card and PIN and biometric. The aforementioned options shall be available depending on the type of card reader utilized. For example, the card reader mode cannot be set to card and PIN if the card reader does not have a keypad. At the end of the time zone, the card reader can return to its default operational mode or be set to any of the aforementioned modes. Each card reader shall have the ability to have multiple time zone setting overrides assigned to them as required by the System Administrator. hh) On-Line Context Sensitive Help The SYSTEM shall provide on-line context sensitive help files to guide System Administrators and System Operators in the configuration and operation of the SYSTEM. The help menu shall be available from any window in the SYSTEM by pressing the F1 function key or clicking on the Help icon in the toolbar. Help windows shall be context sensitive so System Administrators can move from form to form without leaving the help window. Standard Windows help commands for Contents, Search, Back, and Print shall also be available. The SYSTEM shall also come with complete on-line documentation on the product disc. ii) Monitor Zones The SYSTEM shall provide System Administrators with the ability to segment their access control SYSTEM field hardware devices into various zones or areas, which can then be monitored from alarm monitoring client workstations. These zones shall be assigned an alphanumeric name using up to 128 characters and shall consist of one or more access panels, card readers, alarm panels, alarm inputs, alarm outputs, card reader auxiliary alarm inputs, card reader auxiliary alarm outputs, digital video recorders, video cameras, fire panels, intrusion detection panels, intercom exchanges, intercom stations, personal safety panels, central station alarm receivers, off-line lock panels, a graphical map, along with any associated alarm/event/time zone associations. These zones shall then be assigned to the alarm monitoring client workstations that will monitor the assigned areas. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 56

SECTION II

FUNCTIONAL REQUIREMENTS

The SYSTEM shall allow subset relationship devices (such as card readers or ICMs to Intelligent System Controllers) to be automatically part of the monitoring zone when an ISC is selected AND it shall allow the System Administrator to define which subset devices (card readers, ICMs, etc.) belong to that monitor zone. The SYSTEM shall allow for the real time updating of monitor zones. It is unacceptable for System Operators to have to log off of the SYSTEM and re log on each time a monitor zone is modified or updated. In addition, the SYSTEM shall allow for Monitor Zones to be assigned to one or more System Operators. Upon logging into the Alarm Monitoring Workstation, a System Operator shall have the option to override the Monitor Zone to Monitor Station assignment and load the Monitor Zone that is assigned to the System Operator. jj) Advanced Field Device Control The SYSTEM shall allow a System Operator to monitor all alarms in their assigned monitor zone, but only be capable of performing field device control actions on specified devices in the assigned monitor zone. The SYSTEM shall allow System Administrators to set permission control for individual devices within a monitoring zone for command override. For example, System Operators are required to monitor a group of 20 card readers and 100 inputs. However they are only allowed to override (unlock door, mask alarm, etc.) for 5 of the doors and 15 of the inputs. The current list of permissions for control under the monitor permission groups shall include the following: Access modes Open doors Relay and reader outputs Set panel clock Mask alarms and inputs Unmask alarms and inputs Mask alarm mask groups Unmask alarm mask groups Execute function lists Paging E-mail Panel dialup Standalone test mode Download firmware Arm areas Disarm areas Silence area alarms

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 57

SECTION II
kk) Alarm/Event Routing

FUNCTIONAL REQUIREMENTS

The SYSTEM shall be capable of allowing System Administrators to route alarms and events to various alarm monitoring client workstations on the network. The SYSTEM shall allow any alarm or event to be routed to one or multiple client workstations on the network regardless of where the alarm is generated in the field. Alarms shall be routed to client workstations on a device by device level. The SYSTEM shall also allow for the System Administrators to automatically have alarms re-routed from one Alarm Monitoring client workstation to another Alarm Monitoring client workstation if a system operator has not responded to the alarm within a specified amount of time. The SYSTEM shall have network synchronization so that if an alarm/event is routed to multiple client workstations, once the first client workstation grabs the alarm, the alarm/event shall be cleared from all other client workstations. As such, alarms that are routed to an alarm monitoring client workstation which does not have a System Operator logged in shall be queued so that all unacknowledged alarms will report to that client workstation once a System Operator has logged into the SYSTEM. Alarms/Events shall be routed based on default settings or time zone control. The SYSTEM shall allow for alarms and events to be placed into groups that can then be assigned to monitor zones. Each alarm/event that is associated with a group can have its own unique time zone association. The group shall later be used to define when that alarm/event shall be routed to the assigned alarm monitoring client workstation. ll) Text Instructions The SYSTEM shall allow for a set of text instructions to be associated with each alarm that arrives into the SYSTEM. The text instruction function shall allow the System Administrator to enter a minimum of 32,000 characters of text for procedures to follow for each alarm that arrives at the alarm monitoring client workstations. Each alarm or event in the SYSTEM shall have its own unique set of text instructions should the System Administrator desire. mm) Customizable Voice Instructions

The SYSTEM shall allow for a customizable voice instruction to be associated with each alarm that arrives into the SYSTEM. The customizable voice instruction feature shall allow the System Administrator to record a voice instruction of unlimited length. This voice instruction shall explain the procedures to follow once the alarm has been selected for acknowledgment at the alarm monitoring client workstation. Each alarm or event in the SYSTEM shall have its own unique customizable voice instruction should the System Administrator desire. The SYSTEM shall allow both a text instruction and a customizable voice instruction to be associated with each alarm/event configured in the SYSTEM.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 58

SECTION II

FUNCTIONAL REQUIREMENTS

A BROWSE button shall be available to allow the use of pre-existing wave (.wav) files for customized voice instructions. nn) Customizable Voice Annunciation The SYSTEM shall allow for a customizable voice annunciation to be associated with each alarm that arrives into the SYSTEM to be used as an additional attention grabber for high priority alarms. The customizable voice annunciation shall allow the System Administrator to record a voice annunciation of unlimited length, which will annunciate at the alarm monitoring client workstation when the alarm arrives at the SYSTEM. Each alarm or event in the SYSTEM shall have its own unique customizable voice annunciation. This annunciation shall also be user configurable to repeat in user defined one second increments until the alarm is acknowledged. This feature shall have the ability to be muted at the alarm monitoring client workstation at the System Operators discretion. A BROWSE button shall be available to allow the use of pre-existing wave (.wav) files for customized voice annunciations. oo) Alarm Attributes The System Administrator shall have the capability to configure how the SYSTEM handles the annunciation of alarms on an individual basis. Each alarm and/or event shall have the option(s) to: 1. Display at one or more alarm monitoring client workstation. 2. Allow higher priority alarms to be displayed on the alarm monitoring client workstation ahead of lower priority alarms. 3. Require that the field device that generated the alarm be restored to its normal state before the alarm can be cleared from the alarm monitoring window. 4. Print the alarm to the local event printer. 5. Have a customized voice message annunciate at the client workstation. 6. Have the alarm breakthrough to the alarm monitoring window should the System Operator be working on another application on the alarm monitoring client workstation. 7. Allow System Operators to change the journal entry once the alarm has been acknowledged. 8. Require that the alarm not be deleted from the alarm monitoring window upon acknowledgment. 9. Display text and audio instructions outlining the procedures to follow when responding to the alarm. 10. Automatically call-up associated maps upon grabbing an alarm. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 59

SECTION II

FUNCTIONAL REQUIREMENTS
11. Automatically call up the associated cardholder record with photo when the alarm displays. 12. Automatically call up the associated cardholder photo in the video verification function when the alarm displays for comparison to a live video image at the card reader. 13. Require System Operators to enter in a password to view the alarm. 14. Require System Operators to enter in a password to acknowledge the alarm. 15. Require System Operator acknowledgment to clear. 16. Allow mandatory journal entry upon acknowledgment. 17. Have pre-defined canned journal entries for alarms in the SYSTEM. 18. Allow non-essential events to be cleared without requiring System Operator journal entry, while other alarms shall require System Operator journal entry. 19. Send CCTV interface commands to appropriate matrix switchers. 20. Automatically send an e-mail message to one or more e-mail recipients. 21. Automatically send an alphanumeric page to one or more pagers. 22. Have the alarm appear on the alarm monitoring window with a flashing colored bar across the alarm for high priority alarms. Each priority in the SYSTEM shall have its own unique color assigned to it. A minimum of 255 colors must be available for assignment to a minimum of 255 priority levels. 23. Have the alarm, when acknowledged, display a different flashing colored bar across the alarm than for the original alarm color. Each acknowledged priority in the SYSTEM shall have its own unique color assigned to it. A minimum of 255 colors must be available for assignment to a minimum of 255 priority levels. 24. Have a function list(s) assigned to it that will trigger when the alarm is acknowledged. The function lists shall be configured to execute only within a specified amount of time from when the alarm was generated. 25. Require User Logon for Acknowledgment This feature shall require a user ID and password to be entered when the given alarm is acknowledged. This ID shall be different than the User ID that is currently logged onto the SYSTEM.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 60

SECTION II
pp) Alarm-Event Mappings

FUNCTIONAL REQUIREMENTS

The SYSTEM attributes described above shall be assignable on a global basis by System Administrators to all devices that share an alarm description. Thus, the door forced open alarm attributes shall apply to any door with a card reader that is forced opened in the SYSTEM. System Administrators shall have the ability to assign a unique group of alarm attributes to specific device/alarm combinations to override the global settings for specific case settings. For example, System Administrators may assign a different set of attributes to be applied to a door forced open at a bank vault or research facility than they would if the front door was forced open. The SYSTEM MUST allow for this type of flexibility. Each device/alarm combination shall have the ability to have its own unique attribute set if the System Administrator desires. qq) System Downloads After configuring field hardware devices, the SYSTEM shall allow database information to be downloaded to the Intelligent System Controllers (ISCs). Downloads shall load SYSTEM information (time zones, access levels, alarm configurations, etc.) into the ISCs first, followed by cardholder information and card reader configurations. The SYSTEM shall have the ability to configure individual ISCs to receive selective downloads. This ability shall allow a System Administrator to perform a database download, and depending on the ISCs configuration, either a full download of all allowed Access Levels or a selective download of specified Access Levels shall occur. When Selective Download is enabled for an ISC, badge holders who are in an Access Level that was not downloaded shall be required to present their badge twice the initial time they present their badge at a panel. The badge data shall be downloaded after the first presentation. The first presentation will result in a Badge not in Panel alarm in Alarm monitoring. The badge shall then operate normally for all following presentations. Downloading the database to a panel shall delete from that panel all badge holders not in an Access Level designated for download. Bi-directional information flow shall occur so that alarms will still report to their respective alarm monitoring client workstations as cardholder information is being downloaded. The SYSTEM shall allow for System Administrators to grant permission to System Users to download firmware and the database to the entire system. System Users without permission to complete firmware downloads to the entire system still shall be able to perform database downloads, but not be able to download the entire system. Downloads of ISCs shall have the ability to be scheduled such that they will automatically occur at a pre-determined time without System Operator intervention. A complete database download of 10,000 cardholder records to all ISCs (regardless of the number of ISCs) must be complete within ten (10) minutes.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 61

SECTION II

FUNCTIONAL REQUIREMENTS

Information on cardholder status, badge status, time zones or access levels shall not require System Operator intervention to download to the ISCs and shall download in a real time basis as they are added, modified, or deleted from the SYSTEM. Thus, any change made to the aforementioned items shall be downloaded immediately to all ISCs in the SYSTEM. rr) Card Reader Options System Administrators shall have the ability to set the following options for each card reader configured in the SYSTEM: 1. Allow User Commands- This feature shall allow keypad functions to be performed at the card readers keypad. All cardholders assigned an access level with the Allow User Commands option checked will have the ability to activate and utilize functions at the card reader with its keypad. 2. Rename Auxiliary Inputs- This feature shall allow System Administrators to rename the card readers auxiliary inputs. As an example, aux input 1at the front door card reader shall now be renamed Motion Detector at Front Door. Card Reader Auxiliary Inputs shall be supported in the SYSTEM as separate, distinct inputs not associated with the card reader. Each card reader auxiliary input shall appear in the SYSTEM Alarm Monitoring Module as its own alarm and shall appear on graphical maps as its own device icon. 3. Rename Auxiliary Outputs- This feature shall allow System Administrators to rename the card readers auxiliary outputs. Card Reader Auxiliary Outputs shall be supported in the SYSTEM as separate, distinct outputs not associated with the card reader. On graphical maps, each output shall appear as its own device icon. 4. Independently Supervise Request to Exit and Door Contacts - This feature shall allow the System Administrator to independently configure the Request to Exit and Door Contacts as Supervised or Unsupervised. 5. Configure Request to Exit and Door Contacts as Normally Open or Normally Closed - This feature shall allow the System Administrator to independently configure the Request to Exit and Door Contacts as Normally Open or Normally Closed. 6. Deny if Duress - This feature shall deny a cardholder access into an area if a duress code is entered at the card readers keypad. It shall generate an alarm at the alarm monitoring client workstation. 7. Assume Door Used - This option assumes that there is not a door contact at the door to monitor door position. This option is generally used for doors located inside a building.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 62

SECTION II

FUNCTIONAL REQUIREMENTS
8. Alarm Masking - This feature shall allow System Administrators to mask any combination of door forced open, door held open, or the card reader auxiliary input alarms on a time zone basis. Different time zones shall be allowed to be assigned to different door alarm types. 9. Activate Outputs - This feature shall allow System Administrators to activate auxiliary outputs attached to the card reader on a time zone basis. 10. Two Card Control - This feature shall instruct the card reader to grant access only if two valid cardholders (with authorized access levels) swipe their cards one after the other. In the event that a second authorized card is not presented within 10 seconds of the first authorized card, the card reader shall reset and the first card will have to be swiped again. 11. Checkpoint This feature shall instruct the SYSTEM that this card reader is a designated stop on one or more guard tours. 12. Do Not Activate Strike on REX - This feature shall allow the SYSTEM NOT to activate the door strike on a request to exit command. 13. The SYSTEM shall have the ability to allow System Administrators to decide, on a time zone basis, when they wish to log access grants, access denies, and card reader status alarms to the database on a card reader by card reader basis. Different time zones shall be allowed to be assigned to different events. Thus, access grants may be logged only after hours, while access denies are logged twenty-four hours a day, seven days a week for the lobby card reader. However, at the research lab card reader, all events including access grants are logged twenty-four hours a day, seven days a week. 14. The SYSTEM shall allow for user definable door strike functionality for each card reader in the SYSTEM. For each card reader, System Administrators shall have the option for the door strike to be active for the entire strike time after a valid card read or have the strike close as soon as the door is opened after a valid card read. 15. The SYSTEM shall allow for user definable door strike functionality for each card reader in the SYSTEM. For each card reader, System Administrators shall be able to specify whether or not to activate the card readers door strike upon a valid request to exit. 16. The SYSTEM shall allow for each card reader to be selected as either an in reader, out reader, or none to allow for ease of reporting time and attendance basic time in and time out data. 17. Enforce Use Limit This option shall enable Card Use Limits at the card reader limiting the number of times that cardholders may use their credential to gain access at the card reader. LENEL - A UTC FIRE & SECURITY COMPANY

OnGuard

Functional Specifications Version 6.3 Series

Page 63

SECTION II

FUNCTIONAL REQUIREMENTS
18. Alarm Shunt The SYSTEM shall have the ability to shunt a door contact of separate intrusion detection systems. When the SYSTEM provides an access granted a dedicated auxiliary output shall first trigger and bypass the door contact of the separate intrusion detection system, and then the door locking mechanism shall unlock. Once the door returns to a secure state the door contact of the separate intrusion detection system shall return to its normal state. 19. Supervise Door Sets the SYSTEM so that the card reader door contact is wired as a supervised input. 20. Relaxed door forced open detection The SYSTEM shall provide an option that when selected shall allow for the door to be opened for an additional three (3) seconds time period after the request-to-exit sensor has been returned to the normal state. 21. The SYSTEM shall allow for one or more access points in a specific area to be armed and disarmed directly from a command control keypad. Only a cardholder assigned an access level with the Arm/Disarm Command Authority option checked shall have the ability to activate and utilize these functions at the keypad. There shall be a LCD display on the command control keypad which shall provide the cardholder with feedback about whether or not a point in the area is armed or disarmed, and which points are in a state of alarm. The user shall then be provided an option to arm or disarm each point in the area. All cardholder control commands, whether successful or not, shall be recorded and displayed at the monitoring station and shall also appear in the audit trail and all relevant reports.

ss) Input Control Module Options System Administrators shall have the ability to set the following options for each input or output configured on the Input Control Modules in the SYSTEM: 1. Alarm Masking - This feature shall allow System Administrators to mask the alarm input on a time zone basis. 2. Local Linkage - This feature shall allow System Administrators to locally link outputs with inputs that are attached to the same ICM/Output Control Module (OCM). Inputs shall be linked to multiple outputs and outputs shall be triggered by multiple inputs. 3. Activate Output - This feature shall allow System Administrators to activate an output tied to the ICM/OCM on a time zone basis. 4. Activate Output Always- This feature shall allow System Administrators to activate an output always.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 64

SECTION II

FUNCTIONAL REQUIREMENTS
5. Configuration of Debounce Times - Debounce time configuration allows System Administrators to control the amount of time that an input state change must remain consistent in order for it to be considered a real change of state, ideal for preventing contact "flickers" from being reported up as changes of state. 6. Configuration of Hold Times - When configuring an Alarm Input, a hold time setting shall be settable from 0-15. When an input goes active and is restored, the hold time is the amount of time in seconds to wait until reporting the input activation as restored. This feature is useful when there is no advantage to log the specific number of times a point is tripped after the initial event. 7. Checkpoint This feature shall instruct the SYSTEM that this input is a designated stop on one or more guard tours. 8. Supervised Input The System Administrator shall specify if the alarm contact on the ICM is a supervised or unsupervised contact. ICMs shall have the ability to consist of supervised and unsupervised alarm contacts on the same ICM if desired.

tt) Entry/Exit Delay System Administrators shall have the ability to set up entry/exit delays for inputs that are attached to any Input Control Module, Single Reader Interface Module, or Dual Reader Interface Module. System Administrators shall have three options for entry/exit delay: 1. Non-Latched Entry: System Administrators shall have the ability to set an input to non-latched entry. When non-latched entry mode is selected and an entry delay is specified, the following procedure ensues. When an input activates, the alarm will not be reported until the Entry delay expires. If the input is still active when the entry delay expires, the alarm will be reported. If the input is not active when the entry delay expires, then the alarm will not report. This is useful to filter out invalid motion detector reads. 2. Latched Entry: System Administrators shall have the ability to set an input to latched entry. When latched mode is selected and an entry delay is specified, the following procedure ensues. When an input activates, the alarm will not be reported until the Entry delay expires. If the input is still active when the entry delay expires AND the alarm has NOT BEEN MASKED, the alarm will be reported. If the input has been masked when the entry delay expires, then the alarm will not report. 3. Exit Delay: System Administrators shall have the ability to set an input to Exit Delay. When an exit delay is specified, the following procedure ensues. When an input activates, the alarm will not be reported (operates as if masked) until the Exit delay expires. If the input is still active when the exit delay expires, the alarm will be reported. If the input is not active when the exit delay LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 65

SECTION II

FUNCTIONAL REQUIREMENTS
expires, the alarm will not be reported. This is useful to secure a door when an individual is leaving.

uu) Intelligent System Controller Options System Administrators shall have the ability to group add, modify, and delete Intelligent System Controllers (ISCs) in the SYSTEM. The SYSTEM shall have a copy command, allowing System Administrators to easily and efficiently add ISCs. The copy command will copy all information configured for an ISC selected and apply those same characteristics to the new ISC being added. System Administrators shall also have the ability mark ISCs as on-line or off-line depending on whether those panels are on-line. The SYSTEM shall also prompt the System Administrator if the System Administrator attempts to configure the number of cardholders (and assets, if applicable) that will be downloaded to an ISC to a number greater than that which the ISCs memory can handle. vv) Basic Integrated Intrusion Functionality System Administrators shall have the ability to define Alarm Mask Groups for sets of points within an ISC or IDRC. These sets of points can then be treated as an intrusion area. Indication of events from these points can be masked (disarmed) or unmasked (armed) through the alarm monitoring application, from a command keypad, and/or from a supported Open Supervised Device Protocol (OSDP) LCD/Keypad device. The SYSTEM shall support Intrusion Mask Groups. The Intrusion Mask Group shall contain intrusion points. These intrusion points shall be individually configured in the SYSTEM. Once intrusion points are assigned to an intrusion mask group it shall be monitored by the SYSTEM to determine the current state of the intrusion mask group. Alarms shall be reported for the intrusion mask group by the SYSTEM based on the current arming mode and state of the intrusion mask group. For each Command Keypad and supported Open Supervised Device Protocol (OSDP) LCD/Keypad device, the System Administrator shall be able to define which Integrated Intrusion commands (Arm/Disarm/Force Arm/View Faulted points) are allowed and whether a credential is required to execute each of them. The System Administrator shall also be able to assign each Integrated Intrusion command to a function key (if supported by the device), and define up to eight 16-character ASCII strings to be continuously scrolled on the device display (if so equipped). The command keypad or OSDP LCD/Keypad device shall have the option of providing at least the following capabilities: Visual and Audible indication of entry and exit delays Current status of any faulted points in the group Audible and visual indication that an alarm has occurred LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 66

SECTION II

FUNCTIONAL REQUIREMENTS

After an alarm occurs, a list of points faulted during the previous armed period leading up to the alarm state When disarmed, an audible chime when programmed point in the group change

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 67

SECTION II 2. Alarm Monitoring

a) Alarms Monitored

FUNCTIONAL REQUIREMENTS

When the SYSTEM is configured, the System Administrator shall assign a default monitor zone to be monitored. The monitor zone shall include default alarm types with default time zones of which the alarm type will be monitored. These monitor zones will then be assigned to an alarm monitoring client workstation. The SYSTEM shall allow for the monitoring of a combination of one or more ISCs, ICMs, alarm inputs, alarm outputs, and card readers. If applicable, the SYSTEM shall also allow the monitoring of a combination of digital video recorders, video cameras, fire alarm panels, intrusion detection devices, central station alarm receivers, intercom exchanges, intercom stations, and personal safety panels. System Administrators shall have the option to define monitor zones to include all sub devices of an ISC and/or digital video recorders or to choose which sub devices of an ISC and/or digital video recorder belong to that monitor zone. Alarm monitoring client workstations shall be configured to annunciate any or all of the following types of alarms: access granted alarms, access denied alarms, system alarms, emergency alarms, and/or area control alarms. The SYSTEM shall allow for automatic update of the list of hardware devices as they are added, modified or deleted from the SYSTEM. Newly configured devices and changes to existing devices shall be reflected in the hardware list automatically. The SYSTEM shall indicate a deleted device by changing the icon and text associated with the device. Upon the next login, the SYSTEM shall remove the device from the hardware tree. b) Alarm Annunciation Configuration The System Administrator shall have the capability to configure how the SYSTEM handles the annunciation of alarms on an individual alarm/event basis. Each alarm and/or event shall have the option(s) to: 1. Display on the alarm monitoring client workstation. 2. Allow higher priority alarms to be displayed on the alarm monitoring client workstation ahead of lower priority alarms. 3. Require the field device that generated the alarm to be restored to its normal state before the alarm shall be cleared from the alarm monitoring window. 4. Print the alarm to the local event printer. 5. Have a customized voice message annunciate at the client workstation.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 68

SECTION II

FUNCTIONAL REQUIREMENTS
6. Have the alarm breakthrough to the alarm monitoring window should the System Operator be working on another application on the alarm monitoring client workstation. 7. Allow System Operators to change the journal entry once the alarm has been acknowledged. 8. Require that the alarm not be deleted from the alarm monitoring window upon acknowledgment. 9. Display text and audio instructions outlining the procedures to follow when responding to the alarm. 10. Automatically call-up associated maps upon arrival. 11. Automatically call up the associated cardholder record with photo when the alarm displays. 12. Automatically call up the associated cardholder photo in the video verification function when the alarm displays for comparison to a live video image at the card reader. 13. Automatically call up live video from a digital CCTV camera to view the area in alarm 14. Allow the System Operator to control digital CCTV camera functions including pan, tilt, zoom, focus, and iris controls. 15. Require System Operators to enter in a password to view the alarm. 16. Require System Operators to enter in a password to acknowledge the alarm. 17. Require System Operator acknowledgment to clear. 18. Allow mandatory journal entry upon acknowledgment. 19. Have pre-defined canned journal entries for alarms in the SYSTEM. 20. Allow non-essential events to be cleared without requiring System Operator journal entry, while other alarms shall require System Operator journal entry. 21. Send CCTV interface commands. 22. Automatically send an e-mail message to one or more e-mail recipients. 23. Automatically send an alphanumeric page to one or more pagers. 24. Have the alarm appear on the alarm monitoring window with a flashing colored bar across it for high priority alarms based on its priority. Each priority in the SYSTEM shall have its own unique color LENEL - A UTC FIRE & SECURITY COMPANY

OnGuard

Functional Specifications Version 6.3 Series

Page 69

SECTION II

FUNCTIONAL REQUIREMENTS
assigned to it. A minimum of 255 colors must be available for assignment to a minimum of 255 priority levels. 25. Have the alarm, when acknowledged, display a different flashing colored bar across the alarm than for the original alarm color. Each acknowledged priority in the SYSTEM shall have its own unique color assigned to it. A minimum of 255 colors must be available for assignment to a minimum of 255 priority levels. 26. Insert and display alarms based on sort order. System Operators can sort on alarms based on alarm priority, time, date, alarm description, card reader, alarm input device, ISC, cardholder, and if applicable, asset scan ID, asset name, intercom station, central station alarm receiver, transmitter, or transmitter input. All sorts MUST be able to be accomplished in one mouse click. 27. Allow the System Operator to be able to find the location of the alarm by using a graphical map, the real-time graphical system status tree, or an alarm menu. A map call-up feature must be provided that will show the map associated with the alarm. 28. Have a function list(s) assigned to it that will trigger when the alarm is acknowledged. 29. Require User Logon for Acknowledgment This feature shall require a user ID and password to be entered when the given alarm is acknowledged. This ID shall be different than the User ID that is currently logged onto the SYSTEM. 30. Activate an Action Group This feature shall allow the System Operator to execute an action group, which shall include one or more actions.

c) Alarm Handling The handling of alarms shall resemble the following steps. A. The System Operator shall select the alarm/event by any one of the following procedures: 1. Clicking with the mouse on the system device map icon representing the alarm 2. Choosing acknowledge from the menu bar 3. Highlighting the alarm/event in the alarm list by clicking the mouse 4. Double clicking on the alarm/event in the alarm list box LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 70

SECTION II

FUNCTIONAL REQUIREMENTS
B. Any of the above choices shall put the System Operator in the acknowledgment window. The acknowledgment window shall display the time, date, and a user-defined description of the alarm, as well as any emergency procedures. The acknowledgment window shall present the System Operator with the following choices: 1. Review instructions or procedures to follow for the alarm 2. Make a journal entry 3. Acknowledge the alarm 4. Listen to audio instructions 5. Print the alarm and instructions to a local printer 6. Review any previous journal entries for this alarm.

Until the alarm is acknowledged, the alarm shall remain in the Main Alarm Monitoring Window and be counted in the alarm status line. System Operators shall have the ability to mark an alarm as In Progress, meaning that a System Operator has recognized the alarm and is working on a response. When an alarm is marked as In Progress, the SYSTEM shall silence any repeating audio notifications on any Alarm Monitoring Workstation in which the alarm was routed and also remove the alarm sprite notification on any graphical maps that may be displaying the alarm. Other System Operators shall be notified that an alarm has been marked as In Progress by an icon next to the alarm in the Main Alarm Monitoring Window. Control of the associated field hardware device from which the alarm was generated through a right-mouse click operation shall be available. For example, a System Operator can open a door via a card reader alarm. All field hardware device icons on any screen can control the associated field hardware through a right-mouse click operation. A rightmouse click will invoke a menu item with all available control options for that hardware device. System Operators shall have the ability to delete the alarm from the alarm monitoring window without acknowledging the alarm. This feature is useful when guards are monitoring access grants to track where cardholders are moving throughout the facility, but do not necessarily want to acknowledge the alarm. The SYSTEM shall provide a text entry field for the System Operator to enter a journal detailing the cause of specified alarms and the actions taken. The journal shall be mandatory for certain alarms/events per the System Administrators discretion. The journal shall allow System Operators to enter an unlimited amount of notes. Choosing Acknowledge from this window shall clear the alarm indicator and store the alarm information and journal to the database.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 71

SECTION II

FUNCTIONAL REQUIREMENTS

Other alarms shall be displayed by the SYSTEM while any alarm is being addressed. If another alarm occurs, the alarm pending counter shall increase by one and the new alarm shall enter into the alarm list box prioritized in a sort order as defined by the System Operator. Up to 255 alarm priorities shall be available. The SYSTEM shall allow journals to be retrieved, viewed, and edited on screen to provide the System Operator with the ability to complete unfinished journal entries. Journals shall be saved to the database and to a tape during database back-ups for a permanent record as required by CUSTOMER regulations. For card reader alarms, the SYSTEM shall allow System Operators to activate, deactivate, or pulse any or all of the card reader outputs configured and associated with the card reader. The System Operators shall also have the ability to mask or unmask each individual card reader door forced open alarms, door held open alarms, and either or both or the auxiliary alarm inputs configured and associated with the card reader. d) Current Status Indication The alarm monitoring window shall provide a status indicator that displays the current status of alarms, card readers, ISCs and ICMs for the following conditions: 1. Pending alarm shall indicate the number of alarms in the alarm list. 2. Off-line status shall indicate the number of card readers, ICMs, and ISCs that are not communicating with the alarm monitoring client workstation. The ISCs shall be marked with a red X to indicate that they are off-line. If an ISC is marked as off line all child devices below it shall be marked with a yellow X to indicate that they are also off-line, but may come back online when communication is reestablished with the ISC. 3. The Graphical System Status Tree shall indicate all inputs that are currently in an alarm state. If a door alarm has been acknowledged, but the door remains open, the Graphical System Status Tree shall count that door. 4. Off-line and Off-normal status indications shall be viewed graphically through the system hardware tree. 5. Maximum Event, Current Cardholder and Maximum Cardholder Capacity for ISCs shall be viewed graphically through the system hardware tree. 6. If applicable, the amount of hard drive space consumed by stored video on the digital video recorder shall be viewed in the system hardware tree. e) Pending Alarm Windows The SYSTEM shall support a Pending Alarm Window in the Alarm Monitoring Workstation. This shall be a separate window from the Main Alarm Monitoring Window that shall be opened at any time to view a list of only pending alarms. The Pending Alarm

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 72

SECTION II

FUNCTIONAL REQUIREMENTS

Window shall be optionally displayed in conjunction with the Main Alarm Monitoring Window. The Pending Alarm Window shall continuously update as new pending alarms are generated and as existing pending alarms are acknowledged or deleted. Pending alarms shall also display in the Main Alarm Monitoring Window. The Pending Alarm Window shall operate and function in the same manner as the Main Alarm Monitoring Window described throughout this document. f) Device Group Support The SYSTEM shall support device grouping for uniform command and control of groups of devices within the system. Four types of homogeneous device groups shall be supported: 1. Card Reader Groups 2. Input Groups which shall include Alarm Inputs from Input Control Modules and Card Reader Auxiliary Inputs 3. Relay Output Groups which shall include Relay Outputs from Output Control Modules and Card Reader Auxiliary Outputs 4. Video Camera Groups System Administrators shall have the ability to group individual devices into Card Reader Groups, Input Groups, Relay Output Groups, and Video Camera Groups for control within the SYSTEM Alarm Monitoring Module. An unlimited number of Device Groups shall be supported in the SYSTEM and each Device Group shall support an unlimited number of devices. Devices shall have the ability to be placed into multiple Device Groups. Once grouped, the following commands and functions shall be performed within the SYSTEM Alarm Monitoring Module: (1) Card Reader Group Commands (a) Open Doors (b) Change Card Reader Access Modes (c) Mask Door Forced Open/Door Held Open (d) Unmask Door Forced Open/Door Held Open (e) View the Map of the Devices (f) Test the Door Forced Open Alarm (g) Test for Access Grants (2) Alarm Input Commands (a) Mask Alarm Inputs (b) Unmask Alarm Inputs LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 73

SECTION II
(c) View the Map of the Devices (d) Test the Alarm Inputs (3) Relay Output Commands (a) Activate the Relay Outputs (b) Deactivate the Relay Outputs (c) Pulse the Relay Outputs (d) View the Map of the Devices (4) Video Camera Groups

FUNCTIONAL REQUIREMENTS

(a) View Video Tours The ability to automatically switch (sequence) the live video between video cameras in the video group in user defined one-second increments. g) Color Coding for Alarm Priorities The SYSTEM shall allow alarms to appear on the alarm monitoring window with a flashing colored bar across the alarm for alarms configured as high priority. The flashing bar shall have the ability to flash across just the first column in the alarm row or flash across the entire alarm row. The color shall be based on the alarms priority as defined by the System Administrator. Each priority in the SYSTEM shall have its own unique color assigned to it. A color shall also have the ability to be assigned to a range of priorities should the System Administrator desire. A minimum of 255 colors must be available for assignment to a minimum of 255 priority levels. h) Color Coding for Acknowledged Alarm Priorities The SYSTEM shall allow acknowledged alarms to appear on the alarm monitoring window with a flashing colored bar across the alarm for alarms configured as high priority. The flashing bar shall have the ability to flash across just the first column in the alarm row or flash across the entire alarm row. The color shall be based on the alarms priority as defined by the System Administrator and shall be different than the color for that priority when the event was in alarm state. For example a Door Forced Open alarm shall appear with a red flashing bar, but a Door Forced Open alarm that has been acknowledged shall appear with a blue flashing bar. Each priority in the SYSTEM shall have its own unique acknowledged color assigned to it. A color shall also have the ability to be assigned to a range of priorities should the System Administrator desire. A minimum of 255 colors must be available for assignment to a minimum of 255 acknowledged priority levels. i) Highlighting of Unacknowledged Alarms The SYSTEM shall allow for unacknowledged alarms to automatically be displayed in a pop-up window after a user defined amount of time. The user defined amount of time shall be set in System Administration.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 74

SECTION II

FUNCTIONAL REQUIREMENTS

j) Pre-Defined Canned Alarm Acknowledgment Responses The SYSTEM shall allow System Administrators to pre-define alarm acknowledgment responses for alarms in the SYSTEM. These canned responses shall speed up the time it takes System Operators to acknowledge alarms in the SYSTEM and shall be unlimited in length. An unlimited number of canned responses shall be able to be configured for each alarm in the SYSTEM. k) Cardholder Record Call-up From the alarm monitoring window, the System Operator must be able to display a cardholder record with the stored cardholders image. This feature shall be user configurable to be automatic meaning that the Cardholder Window will automatically appear on the Alarm Monitoring client workstation on cardholder activity and will display the current cardholders information with photo. The Cardholder Window will automatically update with updated cardholder information as additional cardholder activity is generated. This feature shall be provided at all alarm monitoring client workstations to assist the System Operator in determining the access rights of an employee who may have forgotten his or her badge or to verify that the individual presenting the card is the correct individual cardholder. Utilizing a database search via the input of the cardholder's name or other key search field, or by selecting a cardholder record call-up from the main monitoring window on a cardholder alarm, the SYSTEM must access the employee's personnel file, containing pertinent information and the employee's image for identification by the System Operator. The System Operator shall not be required to exit alarm monitoring to view this information and this operation must not restrict the operation of monitoring alarms. In the event of an access denied or access granted card reader alarm signal to the alarm monitoring client workstation, this function shall be available as a menu or mouse selection, based on the alarm event. Data input by the System Operator shall not be required. l) Inactive Badge Alarm The SYSTEM shall provide an alarm, indicating current badge status, if an attempt to gain access is made with a badge thats status is set to any value other than Active in the card holder record. Typical inactive badge status values include Lost and Terminated. Access shall be denied for this attempt. By default, the SYSTEM shall come with this feature disabled, the System Administrator has the ability to enable this functionality.

m) Request to Exit Event The SYSTEM shall provide an event when a Request to Exit (REX) is used. By default, the SYSTEM shall come with this feature disabled, the System Administrator has the ability to enable this on a reader by reader basis.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 75

SECTION II
n) Real-Time, Live Video User Verification

FUNCTIONAL REQUIREMENTS

From the alarm monitoring window, the SYSTEM shall interface to the CCTV system and a live CCTV image shall be presented to a System Operator selecting any card read alarm (e.g.: access denied: wrong time zone, wrong access level, badge voided, stolen, etc.). CCTV/Image Comparison shall be available from the Live Video Verification Window. This function shall automatically activate a camera located near the card reader in alarm and search up the database image of the cardholder. It shall display both the live video at the card reader and the stored cardholder image on the alarm screen for System Operator comparison of the images. This shall allow immediate System Operator comparison of the live video of the cardholder at the card reader and the stored image on record of the cardholder. This feature shall be user configurable to automatically show the video verification screen upon cardholder activity at the specified card readers. The SYSTEM shall give System Operators the ability to choose which card readers shall utilize this feature, whether the feature will activate on access grants and/or access denies, and whether to show the cardholders stored database image and/or CCTV live video at the card reader. System Operators shall be able to switch between records (images and live video) should multiple records enter the SYSTEM simultaneously or should another alarm that requires Video Verification enter the SYSTEM while Video Verification is active. The SYSTEM shall support an alternate video verification interface that shall utilize video feeds from configured digital video cameras and operate in the same fashion as the aforementioned video verification. o) Cardholder Photo Verification From the alarm monitoring window, the SYSTEM shall optionally display the stored cardholder photo for each credential presented at the user specified reader(s). This function shall allow an operator to verify that the person using the credential matches the stored photo. The system operator shall be able to select from a list of readers. As the cardholder badges through the selected reader their photo shall appear in the Cardholder Verification window. The system operator shall be able to open multiple Cardholder Verification windows to cover multiple readers at the same time. If the Cardholder Verification window is open when the Alarm Monitoring application is closed then the Cardholder Verification window shall open automatically next time the application is launched. p) Cardholder, Card Reader, or any Field Hardware Device Trace From the alarm monitoring window, the System Operator must be able to initiate several traces of cardholders, assets, and/or field hardware devices while monitoring alarms. This information shall be continuously accumulated in the dedicated trace window until the trace is stopped. The trace operations must not interfere with the operation of the alarm monitoring, and be continuous while alarms are monitored. The results of each trace shall LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 76

SECTION II

FUNCTIONAL REQUIREMENTS

be printable on the report printer or displayed on the screen. The traces shall operate independently, such that one trace may stop and start without interfering with another. Trace windows operate independently of each other and the Main Alarm Monitoring Window. Thus, different Alarm Filter sets shall be settable for each alarm window (Main Window and Trace Windows) open in Alarm Monitoring. For example, the Main Alarm Monitoring Window may not monitor Access Grants Events, while one or more of the trace windows are monitoring Access Grants Events. The SYSTEM shall support historical traces. Historical traces shall allow System Operators to specify the date and time range that they would like displayed for the particular device that is being traced. For example, a System Operator may perform a historical trace that shows the last seven days activity at a particular card reader. Events are then added in real-time during and after the database has been searched for historical events. Historical traces shall also have the ability to be run against restored (previously archived) data. The SYSTEM shall allow System Operators to filter alarm types from the history trace window. Alarms that shall be filtered from the trace window are access granted alarms, access denied alarms, system alarms, duress alarms, and area control alarms. If applicable, alarms that shall also be filtered are asset alarms, fire alarms, intercom alarms, central station receiver alarms, video clips, and transmitter alarms. The SYSTEM shall allow for a trace on any ISC, ICM, Alarm Input, Credential, Intrusion Detection Device, Monitor Zone, or card reader to be performed. If applicable, the SYSTEM shall allow for a trace on any asset, intercom, or camera to be performed. q) Single Click/Double Click Device Command Execution The SYSTEM shall support the ability to execute a device command based on either a single click or double click on the field device icon in the System Hardware Status Tree or Graphical Map. For example, double clicking a card reader icon shall pulse open the door for the configured strike time. Whether a Single Click or Double Click is used to activate the command shall be determined on a System Operator basis. r) On the Fly New Login of System Operators The SYSTEM shall allow a System Operator to login over another System Operator who is already logged into the same client workstation. By doing this, alarm monitoring shall remain running and all alarms shall continue to report into the alarm monitoring client workstation as the new System Operator is logging on. This process shall log the first System Operator off of Alarm Monitoring and log the new System Operator on, changing any permissions necessary for that System Operator. s) Auto Exit to Windows 2008/2003/XP/Vista Login Window When a System Operator logs off an alarm monitoring client workstation, the SYSTEM shall be configurable to automatically exit the alarm monitoring application and log the LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 77

SECTION II

FUNCTIONAL REQUIREMENTS

System Operator out of the Windows 2008/2003/XP/Vista Operating System. The SYSTEM shall then bring the System Operator to the Windows 2008/2003/XP/Vista Login Window for the next System Operator to log on. t) Grant/Deny Popup Window The SYSTEM shall have the ability to launch a pop-up window when a request for access is made through global input/output activity, such as when an intercom station is linked to a door. Upon activating the intercom, the pop-up window shall be displayed in the Main Alarm Monitoring Window and the System Operator shall then have the ability to issue a grant or a deny for the open door request. u) Column Configuration The SYSTEM shall allow System Administrators and System Operators to define which columns are displayed in the Main Alarm Monitoring Window. System Administrators and System Operators shall also be able to determine the column order. Columns available for configuration are: 1. Alarm Description 2. Time/Date 3. Panel 4. Panel Time 5. Device 6. Input/Output 7. Cardholder 8. Badge Type 9. Priority 10. Biometric Score The configuration of the columns shall be configurable by System Operators on a per System Operator/client workstation basis. v) Test Mode for Alarm Inputs The SYSTEM shall support a Test Mode for Alarm Inputs. System Administrators shall be able to perform tests on Input Device Groups to verify that all inputs within the group are operational. While in Test Mode, alarms generated from members of the group shall be displayed either on the test alarm monitoring client workstations only, or on all alarm monitoring client workstation to which the alarms are normally routed. If such alarms are displayed on the test workstations, they shall be displayed in a separate window or view. During the test (the duration of the test shall be set by the System Operator), all inputs within the 11. Intrusion Area 12. Text 13. Line Number 14. Intercom Station Called 15. Account Group 16. Transmitter 17. Transmitter Input 18. Asset Scan ID 19. Asset Name

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 78

SECTION II

FUNCTIONAL REQUIREMENTS

group are manually activated in the field. At the end of the time duration, a report shall be generated flagging any inputs for alarms that were not received. During the Test Mode, all alarm operations carry on as normal, such as Global I/O functions, CCTV commands, printer activity, etc. so that System Administrators shall be able to test that functionality as well. w) Test Mode for Door Forced Open The SYSTEM shall support a Test Mode for Door Forced Opens. System Administrators shall be able to perform tests on Card Reader Device Groups to verify that all card readers within the group are operational. Upon entering into Test Mode and for the duration, door forced opens from members of the group shall either be displayed in a separate window/view on test alarm monitoring client workstations or on all alarm monitoring client workstations in which the alarms are usually routed. During the test (the duration of the test shall be set by the System Operator), all doors within the group are manually forced open in the field. At the end of the time duration, a report shall be generated flagging any door forced opens that were not received. During the Test Mode, all alarm operations carry on as normal, such as Global I/O functions, CCTV commands, printer activity, etc. so that System Administrators shall be able to test that functionality as well. x) Test Mode for Access Grants The SYSTEM shall support a Test Mode for Access Grants. System Administrators shall be able to perform tests on Card Reader Device Groups to verify that all card readers within the group are operational. Upon entering into Test Mode and for the duration, access grants from members of the group shall either be displayed in a separate window/view on test alarm monitoring client workstations or on all alarm monitoring client workstations in which the alarms are usually routed. During the test (the duration of the test shall be set by the System Operator), all doors within the group are manually presented with a valid credential in the field. At the end of the time duration, a report shall be generated flagging any access grants that were not received. During the Test Mode, all alarm operations carry on as normal, such as Global I/O functions, CCTV commands, printer activity, etc. so that System Administrators shall be able to test that functionality as well. y) Manual Control From the alarm monitoring window, the System Operator shall have the ability to dictate manual control of all output points or input points connected to the SYSTEM. Control points are defined as any door strike, auxiliary card reader output, or any other relay output point of an Output Control Module (OCM). LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 79

SECTION II

FUNCTIONAL REQUIREMENTS

All SYSTEM outputs shall display upon command from the System Operator in the realtime graphical system status tree that allows the System Operator to pick and choose output points. The list and commands shall be operational without interfering with alarm monitoring operations. If an output is ordered to a setting (on, off, or pulsed for example), and the output is also on time zone control, the last command shall always take precedence. A response from the OCM or card reader that the command has been carried out shall be displayed in a message box in the SYSTEM. All manual control commands shall record into the activity log for the System Operator of the alarm monitoring client workstation. Manual control for card readers shall allow the System Operator to lock the card reader (to not accept any cards), unlock the card reader (allowing free access), pulse the door open, set the card reader to facility code mode, set the card reader to accept credential only, set the card reader to accept credential and PIN, set the card reader to accept credential or PIN, or reset the card reader to its pre-defined default setting. The SYSTEM shall permit OCM relays to be ordered on, off, pulsed, or reset back to a pre-defined default setting by specific output points as chosen by the System Operator. The SYSTEM shall permit input points to be masked or unmasked as chosen by the System Operator. z) Destination Assurance The SYSTEM shall provide an advanced destination assurance feature that reports instances of cardholders not going directly to their required locations after entering a specified card reader checkpoint. Once a cardholder passes through a checkpoint reader, that cardholder shall have a predefined amount of time to reach his or her destination card reader. Destination Assurance proves beneficial for entry and exit readers at hazardous locations, for example, where an alarm can be generated if a cardholder has not exited the hazardous location within a given length of time. aa) CCTV Interface The SYSTEM shall be capable of automated control via an interface with any Closed Circuit Television (CCTV) System installed that utilizes ASCII commands. When the SYSTEM receives an alarm from any monitoring point connected to the SYSTEM, the SYSTEM shall allow a minimum of three (3) ASCII control commands of up to 255 characters each relating to that alarm point to be sent to the CCTV matrix switcher. For example, the string may command a CCTV camera to activate to a programmed CCTV monitor. The SYSTEM shall allow three (3) signals to be sent per alarm input zone or card access alarm: 1. Upon arrival of the alarm at the SYSTEM alarm monitoring client workstation: Activating a VCR to begin real-time recording of the area in alarm. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 80

SECTION II

FUNCTIONAL REQUIREMENTS
2. Upon selecting or review of the alarm by the System Operator at the alarm monitoring client workstation: Shall be used to call-up the camera to view the alarm area when the System Operator chooses the alarm for acknowledgment. Shall allow the camera, monitor, and VCR to be set back to reset positions or normal operation automatically.

3. Upon alarm acknowledgment or clearing the alarm:

The CCTV system requires either a serial RS-232 or a parallel port interface to a microprocessor based SYSTEM. bb)Real-Time, Dynamic Graphical Maps The SYSTEM shall support real time graphical maps that shall be configured to appear in the alarm monitoring client workstation either on command or when specified alarms are selected for acknowledgment. Maps shall be dynamic so that the icons/maps do not have to refresh or repaint each time a new alarm arrives in the SYSTEM. The SYSTEM shall give System Operators the ability to acknowledge alarms from the graphical map without going back into the alarm monitoring window. The SYSTEM shall support all map formats listed below: Adobe Photoshop (.psd) AutoCAD DXF (.dxf) CALS Raster (.cal) Encapsulated Post Script (.eps) GEM/Ventura (.img) IBM IOCA (.ica) JPEG (.jpg) JIFF (.jif) Kodak Photo-CD (.pcd) Kodak Flashpix (.fpx) LEAD (.cmp) Macintosh PICT (.pct) MacPaint (.mac) Microsoft Paint (.msp) Port Net Graphics (.png) Sun Raster (.ras) Targa (.tga) TIFF (.tif) Windows Metafile (.wmf, .emf) Windows Bitmap (.bmp, .dib) WordPerf Raster (.wpg) Zsoft PCS/DCX (.pcx, .dcx)

The SYSTEM shall support map hierarchies or maps within maps. There shall be no limit to the number of maps that shall be nested hierarchically with each other. The SYSTEM shall support user defined icons for field hardware devices. The SYSTEM shall also give System Operators the ability to affect the mode of card readers, open doors, start a trace on a device, mask/unmask alarm inputs, activate an action group, and activate/deactivate/pulse an output from the map icons. The graphical maps shall have the ability to be printed to a local printer.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 81

SECTION II

FUNCTIONAL REQUIREMENTS

Function List icons shall be able to be placed onto the graphical maps and thus, System Operators shall have the ability to control and activate function lists from the graphical maps. Alarm Masking Group icons shall be able to be placed onto the graphical maps and thus, System Operators shall have the ability to view the status of the alarm masking groups and control the groups from the graphical maps. If applicable, video camera icons shall be placed on the graphical maps and thus, System Operators shall have the ability to launch live video from that camera onto the Main Alarm Monitoring Window or perform a trace on the video events for that video camera. If applicable, intrusion detection icons shall be placed on the graphical maps and thus, System Operators shall have the ability to affect the status of the device/alarm or perform a trace on the intrusion events for that intrusion device. Map device icons shall have the ability to dynamically change shape and/or color to reflect the current state of the device. For example a card reader icon shall change to a different shape or color for normal status, door forced open, door held open, cabinet tamper, etc. Maps shall have the ability to be recalled by right clicking the mouse on the alarm that the System Operator would like to view. Should the device icon appear on multiple layers of maps within a hierarchy, the System Operator shall have the ability to choose which map to display. Multiple maps shall be displayed at any single time. Graphical Maps shall have the ability to be printed from the Alarm Monitoring Module. cc) Real-Time Graphical System Status Tree and List Window The SYSTEM shall support a real-time graphical system status tree/list window that graphically depicts all field hardware devices that are configured in the SYSTEM. The real-time graphical system status tree/list window shall list all ISCs, ICMs, alarm inputs, relay outputs, and card readers. The SYSTEM shall display if the ISCs, alarm input panels, alarm output panels, or RIMs are not currently operating with the most current version of firmware. If applicable, the graphical system status tree/list window shall also list all digital video recorders, video cameras, and intrusion detection devices, zones, and areas. The tree/list window shall show the real time status of all these devices (on-line vs. off-line, alarms activated, masking status, etc.). The graphical system status tree/list window shall include three counters:
1.

Active Counter- a counter of the number of active points in the Monitoring Zone. Offline Counter - a counter of the number of offline devices in the Monitoring Zone.

2.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 82

SECTION II
3.

FUNCTIONAL REQUIREMENTS
Masked Counter - a counter of the number of masked points in the Monitoring Zone.

System Operators shall be able to display both list window(s) and graphical system status tree(s). The List Window shall display all hardware devices separately in their own row in the window. The following columns shall exist in the list window:
1. 2. 3.

Device Name ISC/ICM/OCM Name Current Device Status

System Operators shall be able to sort any column in ascending or descending order. System Operators shall also have the ability to choose what types of devices to display in the graphical system status tree or list window. The following choices shall be available:
1. 2.

Include All Devices Include Specified Devices a) Active devices b) Offline devices c) Masked devices

A status bar indicator shall identify the current selections for the list window or graphical system status tree. System Operators shall be able to display multiple graphical system status trees and/or list windows on a single Alarm Monitoring Workstation. The SYSTEM shall give System Operators the ability to acknowledge alarms from the real-time graphical system status tree/list window without going back into the Main Alarm Monitoring Window. The SYSTEM shall also allow System Operators to affect the access mode of card readers, open doors, start a trace on a device, mask/unmask alarm inputs, and activate/deactivate/pulse an output from the tree icons. The system hardware status tree/list window shall have the ability to be printed to a local printer. The SYSTEM shall also allow System Operators to launch a video player to view live video at the video camera selected. Function List icons shall be able to be placed onto the System Status Tree and thus, System Operators shall have the ability to control and activate function lists from the tree. Alarm Masking Group icons shall be able to be placed onto the System Status Tree and thus, System Operators shall have the ability to view the status of the alarm masking groups and control the groups from the System Status Tree.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 83

SECTION II

FUNCTIONAL REQUIREMENTS

Anti-passback area icons shall be able to be placed onto the System Status Tree and thus, System Operators shall have the ability to control area status (open or closed) from the tree. dd)Automatic Credential Deactivation on Lack of Use The SYSTEM shall have an automatic credential deactivation function whereas a cardholders credential will automatically deactivate after an extended period of inactivity. This Use it or Lose it functionality shall allow System Administrators to set a pre-defined time period, based on cardholder badge type, in which cardholders must swipe their card through a card reader in the SYSTEM. If a cardholder does not swipe their badge at a card reader within this time period, the badge will automatically deactivate without System Operator intervention. System Administrators shall then have the ability to reset the credential status at a later date. ee) Alarm Filtering The SYSTEM shall give System Operators the ability to filter out alarm types from the alarm monitoring window that they do not wish to monitor. Alarms that shall be filtered from the alarm monitoring window are access granted alarms, access denied alarms, system alarms, duress alarms, and area control alarms. If applicable, additional alarms shall be filtered from the alarm monitoring window including fire alarms, asset alarms, intercom alarms, central station receiver alarms, intrusion detection alarms, video event alarms, and transmitter alarms. ff) Manual Override of Card Readers The SYSTEM shall support System Operator overrides of card readers configured. System Operators shall be able to manually open a door from the alarm monitoring window, the graphical maps, or the real-time graphical system status tree. System Operators shall also be able to mask/unmask auxiliary inputs, activate/deactivate auxiliary outputs, change the status of the door (to a locked, unlocked, or facility code only mode; or to accept credential only, both credential and PIN, or either credential or PIN) from the alarm monitoring window, the graphical maps, or the real-time graphical system status tree. The SYSTEM shall also support System Operators ability to manually set a reader back to its default mode that was assigned with the original reader configuration. This option shall be available under the controller or reader menus. gg) Alarm Masking The SYSTEM shall support the masking of alarms to be controlled on a time zone basis or by manual control. Masked alarms shall not appear at any alarm monitoring client workstation. System Operators shall have the ability to manually mask or unmask an alarm point from the alarm monitoring window, the graphical maps, or the graphical system status tree.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 84

SECTION II

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support the ability to configure inputs to be unable to be masked. This shall not allow the masking or unmasking commands to be used with the specific input. Also, this input shall not be allowed to be used in any configurations that could cause it to get masked. The SYSTEM shall support Intrusion Mask Groups. The Intrusion Mask Group shall contain intrusion points. These intrusion points shall be individually configured in the SYSTEM. Once intrusion points are assigned to an intrusion mask group it shall be monitored by the SYSTEM to determine the current state of the intrusion mask group. Alarms shall be reported for the intrusion mask group by the SYSTEM based on the current arming mode and state of the intrusion mask group. hh) Manual Overrides of Alarm Points and Relay Outputs The SYSTEM shall support System Operator overrides of alarm points and relay outputs configured in the SYSTEM. System Operators shall have the ability to manually mask or unmask an alarm point and/or activate, deactivate, or pulse a relay output from the alarm monitoring window, the graphical maps, or the real-time graphical system status tree. ii) On-Line Context Sensitive Help The SYSTEM shall provide on-line context sensitive help files to guide the System Administrators and System Operators in the configuration and operation of the SYSTEM. The help menus shall be available from any window in the SYSTEM by pressing the F1 function key or clicking on the help icon in the toolbar. Help windows shall be context sensitive so System Operators can move from form to form without leaving the help window. Standard windows help commands for Contents, Search, Back, and Print shall also be available. The SYSTEM shall also come with complete on-line documentation on the product disc. jj) Sorting Capabilities The SYSTEM shall allow System Operators to arrange the way that alarms and/or events in the Alarm Monitoring Window appear by giving them the ability to sort the alarms and events in the alarm monitoring window. Sort criteria shall be based on priority, time/date, ISC, Card Reader, ICM, Input Device, or Cardholder. If applicable, alarms and events can additionally be sorted based on asset scan ID, asset name, intercom station, intrusion panel, transmitter, or transmitter input. kk) Masking of Successful Command Acknowledgements The SYSTEM shall support the removal of success acknowledgements that are shown in the Main Alarm Monitoring Window after a command has been successfully executed. The SYSTEM shall allow the successful acknowledgements to be removed on a per System Operator basis.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 85

SECTION II
ll) Hardware Update Timer

FUNCTIONAL REQUIREMENTS

The SYSTEM shall utilize a hardware update timer whereas the System Administrator can set how often system status updates take place. These updates are reflected in the status bar and the real-time graphical system status tree. This frequency shall be defined in one minute increments and shall be changed on the fly by System Operators. Immediate changes in hardware status are reflected immediately in the real-time graphical system status tree. mm) Paging Interface The SYSTEM shall support a paging interface seamlessly integrated within the SYSTEM alarm monitoring module. System Operators shall have the ability to send numeric or alphanumeric paging messages from the alarm monitoring module on demand regarding any alarm currently displayed in the Main Alarm Monitoring Window. System Administrators shall also be able to configure the SYSTEM so that specific alarms automatically send numeric or alphanumeric paging messages regarding the alarm. Pages shall have to ability to be sent to multiple pagers if desired. Pager numbers shall have the ability to be pre-programmed so that sending a page shall be accomplished in a minimum number of mouse clicks. The SYSTEM shall allow any pager to be accessed through a paging terminal that communicates through the TAP (Telocator Alphanumeric Paging) protocol. nn) E-mail Interface The SYSTEM shall support an e-mail interface seamlessly integrated within the SYSTEM alarm monitoring module. System Operators shall have the ability to send ASCII text e-mail messages from the alarm monitoring module on demand regarding any alarm currently displayed in the Main Alarm Monitoring Window. System Administrators shall also be able to configure the SYSTEM so that specific alarms automatically send ASCII text e-mail messages regarding the alarm. E-mails shall have to ability to be sent to multiple e-mail accounts if desired. The SYSTEM shall integrate with Microsoft Exchange Server. E-mail addresses shall have the ability to be pre-programmed so that sending e-mail shall be accomplished in a minimum number of mouse clicks.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 86

SECTION II 3. Personnel Management and Enrollment

FUNCTIONAL REQUIREMENTS

The SYSTEM shall incorporate into a single, seamlessly integrated system, the latest in imaging technology and personnel management. The SYSTEM shall be written so that the Personnel Management and Enrollment module of the SYSTEM is created and maintained from the same set of source code as the Access Control & Alarm Monitoring module. The SYSTEM shall generate and store personnel records, as well as monitor badge/credential use throughout the facility. These credentials shall be fabricated at any of the SYSTEM enrollment & badging client workstations configured based on data and images that are input and captured at the time of enrollment. Credential images are to be digitized using industry standard JPEG image compression, and printed using a high quality and environmentally safe direct card printing process. The SYSTEM shall provide features and options that include the following: a) Create and Maintain Cardholder Database A record for each cardholder shall be created in the badging module of the SYSTEM by entering the required data into appropriate data fields. The System Administrator shall be able to define drop-down list box fields for repetitive entered text (e.g.: Department, Division, Title, Building Number, etc.). Drop-down list boxes shall allow the System Operator a variety of pre-defined choices for data input. The screen design shall be configurable to allow the entry of data in any format desired. The tab order shall be configurable, and the cardholder ID field of up to 18 digits shall be optionally generated by the SYSTEM from either manual System Operator entry, automatic selection of the next available ID, or by use of the cardholders social security number. Once all fields have been entered, the SYSTEM shall store the applicant's record to the SYSTEM database. These records must be stored in a central database. Updating cardholder data shall be possible at any time by any authorized System Operator. The SYSTEM shall have a field that allows System Administrators to view the last date and time that a cardholders record has been modified, without running a report. The cardholder form must be user definable to allow System Administrators to layout the cardholder form. A SYSTEM data import function shall be available to pre-load the SYSTEM with personnel records and industry standard image formats. This import function shall be capable of adding records to the database at any time. The database shall have key fields that are sorted in an index to allow for faster searches. The System Administrator shall be able to designate fields as required and/or unique fields. No record shall be added to the database that does not contain information within the required fields. No record shall be added to the database that contains a duplicate value in a field that was designated as a unique field. Only System Operators with delete privileges (assigned by the System Administrator) shall be able to delete records. Deleting a record shall permanently remove the record from the database (including image files) to free up the disk space for further use. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 87

SECTION II

FUNCTIONAL REQUIREMENTS

The System Operator shall have the following functions available when enrolling cardholders: choose a badge type, select access levels, enter personal identification numbers (PIN), and/or any other user defined fields. The SYSTEM shall allow System Administrators the ability to set a default issue code for all first time prints of credentials. The SYSTEM shall also allow System Administrators the ability to auto increment the issue code each time a new Badge is created or to have the System Operator manually enter in a unique issue code each time a new Badge is created. The SYSTEM shall support a minimum of two digits for the cardholder ID issue codes. The SYSTEM shall utilize keyboard or mouse commands that allow System Operators to quickly create a record for any person. The System Administrator shall be able to define drop-down list box fields for the badge type being issued and default values for the other fields based on the badge type. The cardholder form shall also have the option of displaying a cardholder's signature for the record. The cardholder's current Badge information shall also be displayed on the cardholder form complete with Badge ID number, issue code if applicable, activation & deactivation date and time, and the number of times the current badge has been printed. The cardholder form shall also have the ability to display the cardholders stored images in one of two ways. 1. Photo Display - This option displays the optimum quality photo using the JPEG compressed image stored in the SYSTEM database. 2. No Photo - This option does not show a cardholder photo. The cardholder form shall also display cardholder Last Access information. This field will show the last card reader that the cardholder accessed or attempted to access, complete with a time and date stamp. b) Modify Existing Field Names of SYSTEM Cardholder Form The SYSTEM shall provide a method of defining basic user defined fields. It shall allow System Administrators to rename the standard database fields in the cardholder form of the SYSTEM and move the fields to different locations on the form. Additional functionality shall be available in the advanced Forms Designing and Editing Module. c) Cardholder Active Badges A cardholder may possess one or many badges at any one time. If a badge is updated or re-issued, the SYSTEM shall guide the System Operator to first change the existing badges status to the appropriate classification (de-activate) before a re-issue of the new badge occurs. By utilizing the previously captured image and employee record, the SYSTEM must allow for fast and efficient re-issuance of a badge. As this re-issued badge is printed, the LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 88

SECTION II

FUNCTIONAL REQUIREMENTS

SYSTEM shall update its database to remove access rights from the old badge number and activate the new badge number. Each cardholder record shall offer a user definable activation and expiration date field. The activation date shall be changed by a System Operator to establish a future activation date. A System Operator shall be able to re-activate a card that has been previously deactivated. When issuing a new badge to a cardholder, System Operators shall be able to assign the pre-existing badge deactivation date and time to the badge instead of the default deactivation date and time for new badges. The deactivation date and time may be assigned on a per badge type basis. A badge form will keep a complete history of every badge that was assigned to the cardholders record. The history shall be complete with cardholder badge ID, issue code, badge type, badge status, activation & deactivation dates and times, PIN numbers, embossed numbers, and anti-passback information. d) Multiple Active Badges The SYSTEM shall support a user configurable Multiple Active Badge feature. This shall allow cardholders in the System to have up to a user defined pre-determined number of badges active in the SYSTEM at any one time. System Administrators shall have the ability to set the maximum number of active badges allowed in the SYSTEM. e) Assign Access Levels At the time a badge is created it shall be possible to have up to 128 access levels assigned to the cardholders badge plus any precision access groups. For convenience, the System Administrator must be able to define default access levels to be assigned for given badge types. If a System Operator has proper authorization, cardholder access levels shall be modified. When a badge is created with access rights, or modified, that change shall be downloaded to all ISCs immediately upon completion of the change. Record changes for access rights shall affect only the modified record, and shall not require a download of the entire cardholder database. The access changes shall be downloaded to the field hardware as soon as the employee record change is complete. This badge record download shall not effect field hardware operations. When a badge reaches its deactivation date/time the SYSTEM shall automatically deactivate the access rights associated with the badge. All access rights of a badge shall be eliminated after the expiration date. Should the cardholder become authorized for access again, new access rights shall be applicable to the same badge, and re-issue shall not be required. Should an expired cardholder swipe his badge after his card has expired, access shall be denied and an invalid credential alarm event shall be generated to the alarm monitoring client workstation.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 89

SECTION II

FUNCTIONAL REQUIREMENTS

All cardholder information shall be stored for future retrieval or reporting. An access level form shall show System Operators all access levels configured in the SYSTEM and the associated access levels that are assigned to the cardholders current badge. The SYSTEM shall allow the System Operator to double click the mouse on any access level to view all of the card reader and time zone combinations that are assigned to that access level. The SYSTEM shall also support access groups, which shall be assigned to cardholders. Access groups will consist of up to thirty two access levels of which shall be viewed by System Operators by clicking on the desired access group. f) Bulk Assignment/Modification/Deletion of Access Levels System Administrators or System Operators shall have the option for Bulk Assignment, Modification, and/or Deletion of Access Levels to active badges for a group of cardholders. This feature shall allow System Operators to perform a search of the cardholder database and then apply any additions, modifications, or deletions of access level assignments to all active badges for that group of cardholders. g) Search Records The SYSTEM must allow the System Operator to search for records and images using search criteria on any field(s) in the database. The System Operator must be able to enter the search criteria for one or a combination of fields. In addition, partial searches shall be performed. For example, a partial last name search on Fitz might return "Fitzpatrick, "Fitzgerald," or "Fitzerbauch." Using a partial name or letter shall return every record in the database that contains that information in its last name field. The SYSTEM shall support basic Boolean logic searches (greater than, greater than or equal to, less than, less than or equal to, equal to). For example, a last name Boolean Search >B<F will return to the System Operator all records whose last name begins with the letter C, D, and E. These records shall be viewable sequentially using search keys. The SYSTEM shall allow for the System Administrator the ability to limit the ability of a System Operator to search the database. Thus limiting System Operators, who are using alarm monitoring, from searching through records when pulling up the card holder screen from an event. In a query with no matching records, the SYSTEM must display a message within three (3) seconds indicating that there is no match for the key field information supplied. h) Bulk Deletion of Cardholder Records System Administrators shall have the option to perform Bulk Deletion functions for a group of cardholders. This feature shall allow System Administrators to perform a search against the cardholder database and then delete that group of cardholders.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 90

SECTION II
i) Mobile Badging Operations

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support seamlessly integrated Mobile Badging Operations. Mobile Badge shall allow the SYSTEM cardholder database to be replicated onto an off the shelf laptop computer. The laptop computer shall then have the ability to go to remote sites to enroll cardholders into the SYSTEM. At pre-determined time intervals, the Mobile Badge unit shall log onto the SYSTEM network and upload its changes to the Database Server and then synchronize with the Database Server to obtain the latest cardholder database information. j) SYSTEM Credentials The SYSTEM shall utilize card products designed specifically for security applications. The consumable materials shall be industry standard and designed to feed through direct card printers in the case of PVC cards. Proximity cards shall be industry standard and shall come in a variety of styles. 1) Composite Credentials The SYSTEM shall support credit card size, 3.375 x 2.125, UPVC Composite credentials with an ISO standard 30 mil thickness. The cards provided shall be protected against cracking, fading, and breaking. The composite cards shall consist of a PVC surface with a PEIG core. The composite cards shall be printed by placing them in the dye diffusion thermal transfer printer. Traditional paper media inserts shall not be acceptable. The composite cards shall allow a full-frontal or two sided (depending on the printer) print surface out to the edges (depending on the printer), containing a 3/8" highcoercivity magnetic stripe placed to ANSI standards. The composite cards shall be bar code printable. It shall be durable, difficult to alter, consistent in shape and size, and flexible in design. 2) Proximity credentials Proximity shall be an access control/identification technology that utilizes radio frequency (RF) circuits in microchip form. The microchips are encoded and transmit the encoded information when activated. The proximity card shall be used with its associated proximity card readers. The SYSTEM shall be provided with the following proximity card design options: 1. The proximity card shall be a polycarbonate-based card that cannot be run through direct card printers. This card shall offer a clip slot pre-punched. 2. The proximity card shall be a PVC dual technology card that employs both proximity and magnetic stripe technology. It shall comply with ISO standards for thickness (30 mil). This

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 91

SECTION II

FUNCTIONAL REQUIREMENTS
card shall allow the printing of cardholder record fields including photo directly on the card. 3) Smart Cards Contact smart cards shall be utilized for access control/identity verification technology. Through use of an embedded memory chip, protected electronic data shall be stored on the smart card. Standard card configuration shall include cardholder, biometric, and access information. Contact cards shall require insertion into a card reader which interrogates the card via physical contacts. When coupled with a smart card reader, the smart card shall have the processing power to serve as an access control device, for use in network security and physical access control. The SYSTEM must posses the ability to integrate with the ActivIdentity Card Management System. This integration must allows the System Operator the ability to personalize contact smart cards during the badge issuance process. The integration also must allow for communication during such events as badge encoding, activation, deactivation, and deletion. 4) MIFARE Cards Contactless smart cards shall be utilized for access control and/or identity verification. MIFARE cards, developed by Philips Semiconductors, shall be presented to a card reader for a transaction to take place using wireless transmissions. They shall be passive devices, requiring no built-in power source. Power shall be supplied from energy generated in the coil of the card being places within the radio-wave field of the card reader. With MIFARE cards, security shall be handled with challenge and response authentication techniques, data ciphering, and message authentication checks. Uniqueness of cards shall be guaranteed through serial numbers that cannot be altered. Support shall be provided for encoding MIFARE badges with a custom encryption key. This capability will operate in conjunction with readers configured with a matching key, such that these customized credentials will not be recognized by standard MIFARE readers, and standard MIFARE credentials will not be recognized by these customized readers. The SYSTEM shall support GemEasyLink680 and GemEasyAccess332/GemProx P2 encoders. Using the GemEasyLink680 and GemEasyAccess332/GemProx P2 encoders the SYSTEM shall be able to support both 1kByte (8kBit) and 4kByte (32kBit) MIFARE smart cards. The SYSTEM shall support the input of a MIFARE serial number during standalone and inline printing. The SYSTEM shall be able to read the serial LENEL - A UTC FIRE & SECURITY COMPANY

OnGuard

Functional Specifications Version 6.3 Series

Page 92

SECTION II

FUNCTIONAL REQUIREMENTS
number of the MIFARE card during the print process and have it automatically populate the badge ID field. The SYSTEM shall support the creation of genuine, licensed HID format MIFARE badges compatible with standard HID MIFARE readers, without the need to order customized readers from HID. Support shall be provided for the encoding of genuine licensed HID Corporate 1000 format, including full HID Corporate 1000 parity structure, to the HID MIFARE formatted credential. The SYSTEM shall support the creation of vendor-independent Open Encoding Standard (OES) MIFARE badges from completely unprogrammed MIFARE cards. The system shall allow OES badges to be secured with a user-defined MIFARE authentication key for reading, and a different user defined MIFARE authentication key for writing and modification. The encoding shall be compatible with OES-compliant readers from any manufacturer. In addition to the creation of OES badges, the SYSTEM shall be capable of creating OES re-keying cards that will allow the authentication key of OES compliant MIFARE readers to be reprogrammed without vendor assistance. 5) DESFire Cards Contactless smart cards shall be utilized for access control and/or identity verification. DESFire cards shall be presented to a card reader for a transaction to take place using wireless transmissions. They shall be passive devices, requiring no built-in power source. Power shall be supplied from energy generated in the coil of the card being places within the radio-wave field of the card reader. With DESFire cards, security shall be handled with challenge and response authentication techniques, data ciphering, and message authentication checks. Uniqueness of cards shall be guaranteed through serial numbers that cannot be altered. The SYSTEM shall support Integrated Engineering SmartID Pro and Phillips Pegoda encoders. Using the encoders the SYSTEM shall be able to support 16k DESFire smart cards. 6) HID iCLASS Cards Contactless smart cards shall be utilized for access control and/or identity verification. iCLASS cards, developed by HID, shall be presented to a card reader for a transaction to take place using wireless transmissions. They shall be passive devices, requiring no built-in power source. Power shall be supplied from energy generated in the coil of the card being places within the radio-wave field of the card reader.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 93

SECTION II

FUNCTIONAL REQUIREMENTS
With iCLASS cards, security shall be handled with challenge and response authentication techniques, data ciphering, and message authentication checks. Uniqueness of cards shall be guaranteed through serial numbers that cannot be altered. Support shall be provided for encoding iCLASS badges with a custom encryption key. This capability will operate in conjunction with readers that have been ordered with a matching key, such that these customized credentials will not be recognized by standard iCLASS readers, and standard iCLASS credentials will not be recognized by these customized readers. Support shall be provided for the encoding of genuine licensed HID Corporate 1000 format, including full HID Corporate 1000 parity structure, to the iCLASS credential. The SYSTEM shall support HID OEM-100 and OEM-150 encoders. Using the HID OEM-100 and OEM 150 encoders the SYSTEM shall be able to support 2k and 16k iCLASS smart cards. 7) US Government Smart Cards The SYSTEM shall support reading the access control data (FASC-N) from US Government issued Contactless smart cards, including PIV end point dual interface cards, as well as compatible cards such as CAC dual interface cards, so long as the cards conform to the requirements outlined in FIPS-201 and HSPD12. Support shall be provided for reading the 200 bit BCD FASC-N output of FASCN readers, and concatenating the Agency Code, System Code, and Credential Code into a full, globally unique 14 character credential number. The concatenated credential number must be the human-readable equivalent of the three fields in a string. Alternative representations are not acceptable. Support shall be provided for reading the 75 bit Wiegand Binary output of GSA approved FASC-N readers, and concatenating the Agency Code, System Code, and Credential Code fields into a full, globally unique 14 character credential number. The concatenated credential number must be the human-readable equivalent of the three fields in a string. Alternative representations are not acceptable. The SYSTEM shall support mapping and importing of the full FASC-N data contained on TWIC (Transportation Worker Identification Credential) and PIV cards. The Full FASC-N (Hexadecimal) shall be provided as a field in the FASC-N dropdown in the SYSTEM forms designer tool to map to the full FASCN data contained on TWIC and PIV cards. TWIC card values shall be mapped to the corresponding cardholder user defined fields in order to make import possible. A TWIC or PIV import source shall be supported to import the data. If using a LENEL - A UTC FIRE & SECURITY COMPANY

OnGuard

Functional Specifications Version 6.3 Series

Page 94

SECTION II

FUNCTIONAL REQUIREMENTS
TWIC import source, the PIV data shall be imported along with the TWIC Privacy Key and the full FASC-N data. However, if using a PIV import source, only the PIV data shall be imported. A PIN shall be required to import the following PIV data fields: Fingerprints, Facial image, and Printed information. Without a PIN, only these PIV data fields shall be imported: FASC-N, GUID, and Card Expiration Date. The TWIC data shall not require a PIN. It shall be imported into the database for hardware integration use and shall be not visible to the user. The SYSTEM shall support the import of the photograph and fingerprint biometric from the government issued smart card that is compliance with FIPS201. The SYSTEM shall allow for the verification of the cardholders biometric fingerprint against the imported fingerprint. The option of validating the fingerprint and or the import of the biometric shall be configurable SYSTEM wide.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 95

SECTION II 4. Enrollment & Credential Creation

a) Enrollment

FUNCTIONAL REQUIREMENTS

System Operators shall be able to enroll cardholders on a one by one basis. System Operators will fill in all required fields including name and badge type. The SYSTEM shall determine a number of attributes based on the cardholders badge type. These attributes shall be: 1. Default Deactivation Date/Time - The deactivation date/time shall have the ability be set for a pre-determined number of days, months, or years; or for an exact specified date. 2. Default Access Levels 3. Badge Design Layout 4. Which Printer will Produce the Badge 5. Information and Encoding Format to be Encoded onto the Magnetic Stripe Based on the badge type selected, additional fields shall be required for data entry above and beyond the standard required fields. For example, a Contractor badge may require the field Company Representing to be filled in before the badge can be saved and printed. System Operators shall also enter a Badge ID of up to 18 digits for the cardholder. The cardholder Badge ID shall be determined in one of the following manners: 1. Manually entered by the System Operator 2. Automatically generated by the SYSTEM 3. Use of the Social Security Number as the Badge ID number 4. Use of EMPID as the Badge ID number Badge ID ranges shall be able to be pre-defined, if desired, by the System Administrator based on Badge Type. For example, the Employee Badge Type may allow Badge IDs to range from 1-49,999 while the Visitor Badge Type Badge IDs range from 50,000-50,999. Multiple Badge ID ranges may be configured for each Badge Type. System Administrators shall have the option of determining how Badge IDs are generated for each Badge Type. For example, the Employee Badge Type shall generate Badge IDs automatically while Visitor Badge IDs must be manually entered into the system at the time of enrollment. Badge ID ranges may be system wide. For example, all Badge IDs (regardless of Badge Type) must fall within a specific range. System Operators shall have the option of utilizing PIN Codes of up to nine digits, embossed numbers, and anti-passback exemptions for each cardholder who is enrolled in

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 96

SECTION II

FUNCTIONAL REQUIREMENTS

the SYSTEM. System Operators shall also assign any temporary access levels for each cardholder that is enrolled. The SYSTEM shall allow for fast and efficient re-assignment of Badge IDs for use for Temporary badges through use of Re-Assignment Wizards. Re-assignment shall be such that the Badge ID shall be stored in the Audit Trail and reported with the cardholder that was assigned to that Badge ID for the specified period of time. b) Image Capture from a Live Video Source The Enrollment & Badging client workstation must include all equipment required to capture a high quality image with flash lighting. The SYSTEM must be compatible with flash lighting, RGB video cameras, composite input cameras, S-Video input sources, and digital cameras. The SYSTEM shall allow USB connectivity for video cameras that provide that type of connectivity. The badging client workstation shall allow the System Operator to view a live image of the subject prior to image capture. The SYSTEM shall allow the capturing of the cardholder image at a minimum resolution of 1024 x 968. While capturing subjects, the System Operator must have the option of capturing a new image of any subject without affecting the subjects record. The SYSTEM must provide the ability to move, via mouse, a fixed-size "crop window" over any portion of the image displayed on the monitor and store only the image information within the outline of the window. The SYSTEM must provide the ability to change the size of the crop window to capture exactly the size image that the CUSTOMER requires. The SYSTEM shall include the ability, upon command, to preview, on-line and in full color, the badge as it will appear when printed. This preview mode shall require less than 10 seconds to create a complete example of the badge online. The System Operators shall have the ability to freeze and unfreeze the cardholders photo as many times as required to obtain exactly the image that is desired. The frozen image shall not be saved to the database until the cardholder record is saved. SYSTEM image capture, storage, and hardware compression techniques must be in compliance with the ANSI standard or JPEG (Joint Photographic Experts Group). Cardholder images must be stored as Binary Large Objects (BLOB) within the cardholder record, regardless of how the image was captured. c) Image Capture from a Scanner or Digital Camera The SYSTEM shall give the System Operators the ability to capture a cardholders image through the use of any industry standard scanner or digital camera that utilizes a TWAIN interface. Images shall be able to be scanned in at up to 16.7 million colors for a true color scanned image.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 97

SECTION II

FUNCTIONAL REQUIREMENTS

The SYSTEM must provide the ability to move, via mouse, a fixed-size "crop window" over any portion of the image displayed on the monitor and store only the image information within the outline of the window. The SYSTEM must provide the ability to change the size of the crop window to capture exactly the size image that the CUSTOMER requires. The SYSTEM shall include the ability, upon command, to preview, on-line and in full color, the badge as it will appear when printed. This preview mode shall require less than 10 seconds to create a complete example of the badge online. Certain digital cameras create multiple resolutions of the same image when capturing a photo. The SYSTEM shall allow System Operators to select which image to save when importing an image from a multi-resolution file. SYSTEM image capture, storage, and hardware compression techniques must be in compliance with the ANSI standard or JPEG (Joint Photographic Experts Group). Cardholder images must be stored as Binary Large Objects (BLOB) within the cardholder record, regardless of how the image was captured. d) Image Import The SYSTEM shall allow for System Operators to have the ability to import a cardholders image at the time of enrollment. The SYSTEM must support the following image formats: Bitmaps (.bmp, .dib) JPEG (.jpg) JIFF (.jif) Zsoft PCX/DCX (.pcx, .dcx) Adobe Photoshop (.psd) CALS Raster (.cal) GEM/Ventura IMG (.img) IBM IOCA (.ica) WordPerfect Raster (.wpg) Macintosh PICT (.pct) Portable Network Graphics (.png) TIFF (.tif) Windows Metafile (.wmf, .emf) Targa (.tga) Kodak Photo CD (.pcd) Kodak Flashpix (.fpx) Encapsulated Post Script (.eps)

The SYSTEM must provide the ability to move, via mouse, a fixed-size "crop window" over any portion of the image displayed on the monitor and store only the image information within the outline of the window. The SYSTEM must provide the ability to change the size of the crop window to capture exactly the size image that the CUSTOMER requires. The SYSTEM shall include the ability, upon command, to preview, on-line and in full color, the badge as it will appear when printed. This preview

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 98

SECTION II

FUNCTIONAL REQUIREMENTS

mode shall require less than 10 seconds to create a complete example of the badge online. The SYSTEM shall give System Administrators the ability to set a default directory of the location of the pre-defined images within the Windows directory structure. SYSTEM image capture, storage, and hardware compression techniques must be in compliance with the ANSI standard or JPEG (Joint Photographic Experts Group). Cardholder images must be stored as Binary Large Objects (BLOB) within the cardholder record, regardless of how the image was captured. System Administrators shall have the option to set the image capture window default settings of how the image capture window will appear when enrolling cardholders (live video, scanner, or file import). System Operators, with proper privileges, shall have the option to override the SYSTEM defaults. e) Auto-crop the Enrollment Photograph The SYSTEM shall allow the image being captured/imported to be automatically cropped based on the location of the eyes in the captured/imported image. The SYSTEM shall also allow the operator to override the auto-crop with a manual crop window. f) Business Card Scanner Enrollment The SYSTEM shall support an integrated business card scanner for automatic population of specific visitor information fields. The VMS shall support the Corex CardScan business card scanner. g) ID Scanner Enrollment The SYSTEM shall support an integrated Drivers License, passport, government ID, and military ID scanner for automatic population of specific visitor information fields, photo, and signature. The VMS shall support the IDScan CSS-800 and CSS-1000 scanners. The SYSTEM shall support bar-code scanning for both scanners. h) Biometric Verification Biometric verification shall be available as a seamlessly integrated solution with other Total Security Knowledge Management Modules. Through the measurement and comparison of human characteristics such as fingerprints, hand geometry, or Iris imaging, the SYSTEM shall have the capability to verify the identity of enrolled individuals. The SYSTEM shall NOT require the use of the photo capturing license in order to capture biometrics, the license required for biometric capturing must be separate. The SYSTEM shall provide the ability to view, capture, and delete biometric templates. The System Administrator shall be able to provide permission to view, capture, and delete biometric templates to System Operators. The permission to view, capture, and delete inputted biometric templates shall not be all inclusive. For example, some System LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 99

SECTION II

FUNCTIONAL REQUIREMENTS

Operators may only have the ability to capture biometric templates, while others may have the ability capture biometric templates and delete biometric templates. The System Administrator has the ability to assign the System Operator access to any or all of the aforementioned biometric template abilities. Biometric verification shall be available on a time zone basis per reader. For example, card readers on computer labs shall always use card and biometrics, while card readers at other areas use card only during the day and card and biometrics during off hours. Through integration with Schlage Handkey Series and ID3D-R readers, the SYSTEM shall have the ability to seamlessly capture biometric information (hand geometry) and create biometric templates during the cardholder enrollment process. Biometric verification based on hand geometry shall require the accompaniment of a badge or PIN entry using a reader connected to a Single or Dual Reader Interface Module residing on the same Intelligent System Controller, but physically independent of the Biometric Reader Interface and its devices. In the case of PINs, the integrated RSI keypad shall be used. Through integration with Bioscrypt V-Pass FX and V-Station Series fingerprint readers, the SYSTEM shall have the ability to seamlessly capture biometric information (fingerprint) and create biometric templates during the cardholder enrollment process. Biometric verification based on fingerprint shall require the accompaniment of a badge or PIN entry using a reader connected to a Single or Dual Reader Interface Module residing on the same Intelligent System Controller, but physically independent of the Biometric Reader Interface and its devices. In the case of PINs, the integrated keypad of the VStation may also be used. Through integration with Identix V20 Series fingerprint readers, the SYSTEM shall have the ability to seamlessly capture biometric information (fingerprint) and create biometric templates during the cardholder enrollment process. Biometric verification based on fingerprint shall require the accompaniment of a badge or PIN entry using a reader connected to a Single or Dual Reader Interface Module residing on the same Intelligent System Controller, but physically independent of the Biometric Reader Interface and its devices. In the case of PINs, the integrated Identix keypad shall be used. Through the integration with Biocentric Solutions CombiSmart readers, the SYSTEM shall have the ability to verify cardholder identity. With use of the Schlumberger Reflex 72 Serial Smart Card reader in combination with the AuthenTec FingerLoc AF-S2 Sensor, the SYSTEM shall seamlessly capture biometric information (fingerprint) and create biometric templates during the cardholder enrollment process. Biometric verification based on fingerprint shall require the accompaniment of a smart card using a CombiSmart reader connected to a Single or Dual Reader Interface Module.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 100

SECTION II

FUNCTIONAL REQUIREMENTS

Through the integration with Bioscrypt Solutions V-Smart and V-Station readers, the SYSTEM shall have the ability to verify cardholder identity through iCLASS and/or Mifare ISO 14443A and 15693 contact less smart card technologies. The SYSTEM shall seamlessly capture biometric information (fingerprint) and create biometric templates during the cardholder enrollment process. Biometric verification based on fingerprint shall require the accompaniment of a smart card using a Bioscrypt reader connected to a Single or Dual Reader Interface Module. The SYSTEM shall also support Bioscrypt two finger capture. Bioscrypt two finger capture shall allow for the capture of a Bioscrypt formatted primary and secondary fingerprint per cardholder. This information shall be encoded on a smart card. Through the integration with Integrated Engineering SmartTouch Mifare reader, the SYSTEM shall have the ability to verify cardholder identity through Mifare ISO 14443A contactless smart card technology. The SYSTEM shall seamlessly capture biometric information (fingerprint) and create biometric templates during the cardholder enrollment process. Biometric verification based on fingerprint shall require the accompaniment of a Mifare smart card using a Integrated Engineering SmartTouch reader connected to a Single or Dual Reader Interface Module. The SYSTEM shall also support Bioscrypt two finger capture and encoding for the IE SmartTouch reader. Bioscrypt two finger capture shall allow for the capture of a Bioscrypt formatted primary and secondary fingerprint per cardholder. This information shall be encoded on a smart card. The SYSTEM shall support configuring Magnetic and Wiegand card formats as duress formats. When the controller detects a duress format, it reports events as duress rather than normal. This setting is different from the Deny On Duress PIN setting for readers that accept PIN input. The system ignores the duress format setting during badge encoding. If the reader is capable of reversing bit order, a Wiegand card format can be configured with a reserved bit order format. When the controller detects this format, it reverses the bit order of the incoming data before processing it. The system ignores this setting during badge encoding. The addition of Duress and Reverse Bit Order Card Format capabilities enable OnGuard to support Bioscrypt Duress Finger function. The SYSTEM shall allow for duress finger support. Duress finger support shall allow users of Bioscrypt Smartcard readers and/or IE SmartTouch MIFARE readers to capture a primary and a duress fingerprint, and then to generate an "Access Granted - Duress" event if the duress finger is used. The mechanism for achieving this shall be to define different card formats on the panel for the nonduress card data vs. the duress card data. Both the IE and the Bioscrypt provide different data when a duress event occurs. When capturing a Bioscrypt fingerprint, the SYSTEM USER shall have a choice between designating a 2nd fingerprint as either "secondary" (normal access with second finger) or "duress" (duress access with second finger). The default mode for the second finger shall

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 101

SECTION II

FUNCTIONAL REQUIREMENTS

be preserved between captures and between sessions, to prevent the need for repetitive selection of the same value. The IE SmartTouch MIFARE, V-Smart MIFARE, and V-Smart iCLASS formats shall properly flag the second Bioscrypt template as either secondary or duress, as indicated in the capture process. Through the integration with LG Electronics Iris Scan readers, the SYSTEM shall have the ability to verify cardholder identity through iCLASS contact less smart card technologies. The SYSTEM shall seamlessly capture biometric information (iris) and create biometric templates during the cardholder enrollment process. Biometric verification based on iris shall require the accompaniment of a smart card using a LG reader connected to a Single or Dual Reader Interface Module. Through the integration with HID bioCLASS fingerprint readers, the SYSTEM shall have the ability to verify cardholder identity through iCLASS contactless smart card technologies. The SYSTEM shall seamlessly capture biometric information (fingerprint) and create biometric templates during the cardholder enrollment process. Biometric verification based on fingerprint shall require the accompaniment of a smart card using a bioCLASS reader connected to a Single or Dual Reader Interface Module. The SYSTEM shall utilize a Sagem-Morpho MSO-300, MSO-350, or MSO-1300 USB capture device to capture fingerprints directly into the primary system database, to be encoded onto bioCLASS badges by the SYSTEM. It is not acceptable for fingerprint capture to be done external to the SYSTEM using a standalone bioCLASS device. Through the integration with Cross Match ID-500, Crossmatch Verifier 300, or the Sagem-Morpho MSO-300, 350, or 1300, the SYSTEM shall have the ability to capture up to ten fingerprints per enrolled person. This format MUST meet requirements for background checks AND shall also be able to be used with access control systems. The Cross Match ID-500 shall posses a method to recapture all or individual fingerprints depending on the image quality. The Cross Match ID-500 and Verifier 300 shall contain the ability to provide feedback on image quality. All biometric templates shall be stored within the SYSTEM database, and in some cases, the Intelligent System Controller. Additionally, the smart card shall store cardholder, fingerprint, and access information. 1) Seamless Integration

Seamless Integration with Access Control and Alarm Monitoring System

Biometrics shall seamlessly integrate with the Access Control & Alarm Monitoring System. Biometric verification alarms shall report in the same Main Alarm Monitoring Window as access control alarms and shall be handled in an identical manner. The same database and network MUST store and transfer information for biometrics and the Access Control & Alarm Monitoring System. A separate database and/or network for the two systems is unacceptable. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 102

SECTION II

FUNCTIONAL REQUIREMENTS

Seamless Integration with the Credential Management System

Biometrics shall seamlessly integrate with the Credential Management System. Biometric information shall be stored in the SYSTEM database along with cardholder information. The same database and network MUST store and transfer information for biometrics and the Credential Management System. A separate database and network for the two systems is unacceptable. 2) Enrollment Biometric templates shall be created during the badge enrollment process or added to existing badges in the SYSTEM database. Biometric information shall also be stored at Intelligent System Controllers, along with badge information. If a smart card is used, cardholder, biometric, and access information shall be added to the smart card. System Operators shall be able to enroll biometrics templates on a one by one basis. System Operators shall fill in all required fields. The biometric data shall be captured via the configured enrollment reader specified. Biometric enrollment readers shall be directly connected to the enrollment workstation. Field hardware connections shall not be required for enrollment readers. 3) Viewing Biometric Templates System Operators shall be able to perform a search of cardholder records to view biometric templates (if there is indeed an image available for viewing) that are currently associated with that cardholder. 1) Federal Agency Smart Credential Number (FASC-N) Standard for Government Badge ID Allocation The SYSTEM shall support the new Federal Credential Number format scheme and file format specifications for Government Smart Cards and Common Access Cards meeting the requirements of GSC-IS v2.1. This specification facilitates efforts to utilize a single credential in physical access control systems across the Federal Government enterprise. The credential number content shall be based upon the format originally described in the Department of Defense (DOD) Security Equipment Integration Working Group specification 012 (SEIWG-012). 2) PACS Card Holder Unique Identifier Low and Medium Protection Profile Support The SYSTEM shall support a range of protection profiles that are in association with an extensible data model on Federal Agency Smart Credential (FASC) Cards. The range of protection profiles shall contain the following profiles: low, medium, and high. Using the methods prescribed for each protection profile, a Physical Access Control System (PACS) shall function for the intended purpose at the adequate level of security warranted by the specific environment and facilitate a cross-agency interoperability LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 103

SECTION II

FUNCTIONAL REQUIREMENTS

across the population of FASC cardholders. The SYSTEM, at a minimum, must provide support for low and medium protection profiles. The low protection profile must most closely emulate the operation of a magnetic stripe card. The medium protection profile shall provide assurance that the card presented was issued by the application holding secret keys, and card was presented to a reader holding symmetric secret keys. 3) Digital Certificate Management The SYSTEM shall support Digital Certificate Services to enable System Operators to securely obtain digital certificates for smart card cardholders. The SYSTEM shall allow a System Operator to enroll and issue the smart card to each cardholder during enrollment process. This shall allow the issuing of a Smart Card Logon certificate (which provides authentication) or a Smart Card User certificate (which provides authentication plus the capability to secure e-mail) for the purpose of Smart Card Login to PCs. The Digital Certificate shall allow cardholders to log on to a computer with a smart card, instead of needing to type CTRL+ALT+DEL. The SYSTEM shall be able to link a SYSTEM cardholder account to the cardholders Active Directory network account. 1. Smart card readers

The SYSTEM shall support any smart card reader(s) that have been tested by the Microsoft Windows Hardware Quality Lab and have obtained the Windowscompatible logo be installed on Windows 2008/2003/XP computers. 2. Supported smart cards The SYSTEM shall support the Gemplus GemSAFE and Schlumberger Cryptoflex smart cards included in the default Windows 2008/2003 installation. 3. System Configuration/Network Account Allocation The SYSTEM shall enforce the allowable number of Network accounts per Cardholder 4. Linking Network Account to Cardholder Accounts System Administrators shall be able to link an existing Windows Active Directory Account to an SYSTEM cardholder account. Conversely, System Administrators shall be able to unlink an existing Windows Active Directory Account to an SYSTEM cardholder account. 5. Manage Certificates Through services such as DataConduIT, IT Administrators shall provide facilities to notify IT of events in the SYSTEM that would potentially lead to certificates

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 104

SECTION II

FUNCTIONAL REQUIREMENTS
being revoked or suspended. Thus, SYSTEM Certificate Services provide facilities to manually perform following actions on issued certificates:
1.

View certificates. The System Administrator shall be able to view certificates issued to a particular cardholder by SYSTEM. Revoke Certificates. Renew Certificates. View Certificate Audit Trail. Each Certificate Authority shall maintain an audit trail of certificate requests and the certificates that are issued until they expire. The audit trail shall record all certificate transactions including failed requests and all of the information contained in each issued certificate. It also shall provide the information that is required to revoke a certificate and add it to the revocation list. System Administrators shall query the audit trail to locate and view information about any certificate request or any certificate that has been issued by the SYSTEM.

2. 3. 4.

4) Card Management System Support a. The SYSTEM shall support any smart card reader that has been tested by the Microsoft Windows Hardware Quality Lab and has obtained the Windowscompatible logo to be installed on Windows 2008/2003/XP Computers. b. The SYSTEM shall support integration with ActivIdentity CMS version 4.0 SP3 or 4.1. c. The SYSTEM shall support issuing of a credential with the self-issuance and local issuance model. For self-issuance the credential will be issued a temporary passcode that will allow the cardholder to login to the ActivIdentity Self Service Portal to complete the issuance process. For local issuance the credential will be given a permanent pin number to secure the credential. The credential will also be completely personalized with all certificates and applications, based on the configuration of the CMS system. d. The SYSTEM shall support verifying the cardholders fingerprint while the card is being issued. This option shall by configurable as a system wide setting. e. The SYSTEM shall read the card serial number during issuance, either inline during the printing process or on a stand-alone PCSC compliant reader/encoder that is connected to the workstation f. The SYSTEM shall support the issuance of a card that either has a pending request from a 3rd party IDMS (Identity Management Server) or create a new request. The issuance of a card based on a previous request, shall be configured as a system wide setting. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 105

SECTION II

FUNCTIONAL REQUIREMENTS
g. The SYSTEM shall support the issuance of a new card and a permanent replacement card. During the issuance of a permanent replacement card the certificates will be transferred to the new card, based on the configuration of the CMS system.

5) Desktop Smart Card Encoding Support The SYSTEM shall support desktop smart card encoding for the following reader and technologies: 1) Integrated Engineering (MIFARE) 2) Bioscrypt V-Smart (iCLASS and MIFARE) 3) Biometric Container (iCLASS and DESFire) 4) GSC (iCLASS and DESFire) 5) LG Iris Access (iCLASS) 6) HID MIFARE 7) HID iCLASS Access Control 6) In-line Smart Card Encoding Support The SYSTEM shall support in-line smart card encoding for the following readers and technologies: 1) Credential Agent 2) Integrated Engineering (MIFARE) 3) Bioscrypt V-Smart (iCLASS and MIFARE) 4) Biometric Container (iCLASS and DESFire) 5) GSC (iCLASS and DESFire) 6) LG Iris Access (iCLASS) 7) HID MIFARE 8) HID iCLASS Access Control 7) Chromakey The SYSTEM shall support an advanced Chromakey feature. Chromakey is the process of removing a solid background from a captured image. Chromakeyed photos are very difficult to reproduce or falsify. The SYSTEM shall have the ability to remove the color that resides in the top left corner of the crop window or remove the color of the System Operators LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 106

SECTION II

FUNCTIONAL REQUIREMENTS

choice. A tolerance setting shall be available for fine tuning images of cardholders whose shirt, hair, etc. is close to the color of the background. 8) Ghosting The SYSTEM shall support a ghosting feature whereby the system will make the cardholders photo semi-transparent to create a ghosting effect. Ghosted images are very difficult to reproduce and falsify. The SYSTEM shall support 256 levels of ghosting from 0 (no ghosting) to 255 (invisible). 9) Signature Capture The SYSTEM shall allow for System Operators to have the ability to capture a cardholders signature. The SYSTEM shall support any signature pad that supports the Penware or the Wintab interface standards. Signatures shall be displayed on screen and cardholders may sign their name as many times as required to get the signature that is desired. Signatures may also be captured by importing a signature file into the SYSTEM or by scanning it in using an industry standard scanning device that utilizes a TWAIN interface. SYSTEM signature capture, storage, and hardware compression techniques must be in compliance with the ANSI standard or JPEG (Joint Photographic Experts Group). Signatures must be stored as Binary Large Objects (BLOB) within the cardholder record. 10) Pre-defined Badge Formats The badge format, including layout, background color, location of photo, text, applicable graphics or company logos, etc., shall be completely and automatically determined by the SYSTEM based on the cardholders badge type. Where choices are available to the System Operator, choices are to be made via pre-defined list boxes to avoid System Operator errors in spelling and badge assignment errors. 11) ID Printers The SYSTEM shall support any printer with industry standard and Microsoft Certified Windows 2008/2003/XP/Vista drivers. The SYSTEM shall support double-sided full color printing on those printers in which double-sided full color printing is available. The SYSTEM shall also support edge to edge printing on those printers in which edge to edge printing is available. The SYSTEM shall support high-speed printing on those printers in which high speed printing is available. The SYSTEM shall also support holographic overlays on those printers in which holographic overlay support is available. 12) Avery Dennison Badge Label Templates The SYSTEM shall provide pre-defined badge layouts in BadgeDesigner that shall be specifically tailored to match Avery Dennisons US and International ID label sheets for production of sticky back credentials. The SYSTEM shall also have print media templates for the following media: LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 107

SECTION II

FUNCTIONAL REQUIREMENTS
Avery 2990 Labels for Access Control Cards (500 count box) Removable Avery 2991 Labels for Access Control Cards (500 count box) Removable, Pre=Punched (Portrait) Avery 2992 Labels for Access Control Cards (500 count box) - Permanent Avery 2993 Labels for Access Control Cards (500 count box) Permanent, Pre-Punched (Portrait) Avery W5000 Photo ID Plastic Card (Usable area defined) Avery W7100 Photo ID Name Badge with Hole (Usable area defined) Avery W9100 Photo ID Name Badge with Hole (Usable area defined) Avery W9150 Photo ID Name Badge without Hole (Usable area defined)

13) Print Limits The SYSTEM shall allow System Administrators to limit the number of times a cardholders credential can be printed. 14) Intelli-Check ID Check Integration The SYSTEM shall integrate with the Intelli-Check ID Check 1400 product that allows the scanning of credentials, such as drivers licenses, military IDs, and government IDs in order to populate the cardholder form during the enrollment process. The Intelli-Check integration shall speed the enrollment process, verify identities and false IDs, and ensure accurate input of information. 15) Batch Printing The System Operator must be able to print a credential immediately or continue enrolling cardholders with the intention of batch printing at a later time. The SYSTEM Badging client workstation shall have the ability to print a large volume of badges with a single command using a search command. The System Operator must have the option of printing all badges, printing selected badges, or pre-viewing badges without printing. The SYSTEM shall have a log errors feature for batch printing. This means that the SYSTEM shall skip any Badges that cannot print due to missing information. For example, in a 200 card batch print job, there may be three cards that require information that is not available because the System Operator failed to enter the information. When printing, the SYSTEM shall skip those three cards and print the other 197. A report can later be run to determine what information is missing for the remaining 3 cards. h) Print Service Bureau Printing The SYSTEM shall support the flagging of records to be sent for printing to a print service bureau. The SYSTEM shall only display the option if it is configured and LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 108

SECTION II

FUNCTIONAL REQUIREMENTS

enabled. Once enabled the credentials selected shall be packaged and stored in the SYSTEM database. The packaged records can then be exported and submitted to a print service bureau. i) In-line Magnetic Stripe Encoding

Utilizing an in-line magnetic stripe encoding device within the printer, the SYSTEM must allow for magnetic stripe encoding of all its permanent credentials. This magnetic stripe shall conform to ABA Track II and ANSI specifications. The SYSTEM shall allow System Administrators to define attributes for card number, facility code and issue code, as well as starting card number. The SYSTEM shall support a multi-track custom encoding feature. System Administrators shall be able to encode user defined custom expressions on any of the three (3) tracks of the magnetic stripe of a credential. The following information shall be able to be encoded on any of the three tracks of the magnetic stripe: (1) Access Control Information (a) Facility Code (b) Card Number (c) Issue Code (2) ASCII Text (3) Database Fields (4) ISO/IEC 7812-1 Check Digit The SYSTEM shall support encoding data onto a JIS II magnetic stripe using JIS IIcapable Fargo printers, including the Persona C30, Persona M30, DTC400, DTC550, HDP600, and HDP5000. j) Image Export

During enrollment, System Operators shall have the ability to export the captured cropped image to an industry standard JPEG (.jpg) file format for use outside the SYSTEM application. These files shall be stored in a pre-defined directory defined by the System Administrator. A prompt shall be available to System Operators for the ability to save the exported image in an alternative directory. k) Real Time User Definable Image Compression The SYSTEM must support a real time user definable image compression utility. The image compression utility shall give System Operators the ability to compare image quality versus compressed image size ratios. This process shall be done in real time and LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 109

SECTION II

FUNCTIONAL REQUIREMENTS

must not require System Operators or System Administrators to go to a program or .ini file outside the program to adjust the ratio. The SYSTEM shall give System Administrators the ability to set SYSTEM default compression settings and give System Operators, with proper permissions, the ability to override those settings. The better the image quality, the larger the image size (affecting hard drive space and speed of records traveling across the network). l) Crop Window Attributes

The SYSTEM shall allow for the image capture crop window to be both movable and sizable. System Administrators shall have the option to give System Operators the ability to size and/or move the crop window. System Administrators shall have the ability to have the SYSTEM maintain the aspect ratio of the image if the captured image is smaller or larger than the pre-defined image object on the badge. m) Real Time User Definable Video Input Settings The SYSTEM shall allow for the real time setting of video input devices. User selectable drop down lists shall be available for RGB, Composite, and S-Video input formats. This process shall be done in real time and should not require System Operators or System Administrators to go to a program or .ini file outside the program to adjust the settings. n) Signature Capture Window Attributes The SYSTEM shall allow for the ability to customize the signature capture window so that the window will be more aesthetically pleasing to System Operators. The SYSTEM shall allow System Operators to change the background and foreground colors to a minimum of sixteen different colors for a total of 256 color combinations. The SYSTEM shall also allow System Operators to have the ability to adjust the signature pen pressure to allow for thicker or thinner signatures. o) Image Processing/Effects Gallery The SYSTEM shall support cardholder image processing of the cropped captured image through use of a pre-defined image effects gallery. The image processing module shall show both the original captured image side by side next to the processed image. The following effects shall be available to System Operators to apply to an original captured image in any combination desired: 1. Intensity - Increases or decreases the overall intensity level of the light in the image. Adjusts the brighter areas by making them brighter or darker. 2. Contrast - Increases or decreases the range of gray levels contained in the image. It adjusts the distinction between the lightest and darkest tones in the image. 3. Saturation - Adjusts the purity of color (the number of colors used to create a particular color).

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 110

SECTION II

FUNCTIONAL REQUIREMENTS
4. Gamma Correct - Enhances detail in the image by adjusting the middle tones without affecting the darkest and lightest areas. 5. HistoContrast - Adjusts the number of pixels per gray level to create a linear relationship between gray levels, used to bring out the detail in dark areas of the image. 6. Hue - Adjusts the main characteristic of a particular color that distinguishes it from other colors. 7. HistoEqualize - Redistributes shades of colors to adjust imbalances. It makes the darkest colors black and the lightest colors white and stretches the colors in-between. 8. Flip - Flips the image horizontally (the image will appear upside down). 9. Reverse - Flips the image vertically, creating a mirror image of the original. 10. Rotate - Rotates the image 0-360 degrees. 11. Shear - Applies the look of three-dimensionality to the image, while maintaining the original size and shape. 12. Add Noise - Creates a granular effect that adds texture to a flat or overly blended picture. 13. Average - Converts each pixel in the image to the average of itself and the pixels to the right and bottom, resulting in a blurring of the image. 14. Sharpen - Enhances the edges and brings out the detail. 15. Halftone - Converts the image to a black and white (1 bit/pixel) image in which different shades of gray (luminance) are represented by different patterns of black and white pixels. 16. Median - Reduces the amount of graininess (noise) in an image. 17. Emboss - Converts the image to a raised relief style with its light source directed from the top left. 18. Gray Scale - Represents the image using up to 256 shades of gray. 19. Invert - Inverts the colors in the image as on a photographic negative. 20. Mosaic - Converts the image to a grid of square blocks of color. 21. Posterize - Reduces the color resolution, which is the number of shades of color that shall be displayed simultaneously. 22. Filleting Rounds the corners for images within a badge layout. 23. Preserved Aspect Ratio Preserves the aspect ratio of images within badge layouts so that the object rectangle is always filled.1

The SYSTEM shall allow for the System Operator to save any combination of effects as a profile to be used on other original images for image processing. These profiles shall be LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 111

SECTION II

FUNCTIONAL REQUIREMENTS

used in conjunction with the image effects gallery. Profiles shall have the ability to be added or deleted from the SYSTEM at any time. The SYSTEM shall ship with a minimum of 6 pre-defined image effects. The SYSTEM shall support an image effects gallery that shall take the original image and apply up to six pre-defined effect profiles to the image. These profiles shall display side by side in a gallery for the System Operator to select. The System Operators shall have the option of choosing which profiles are applied to the original image in the gallery by selecting from all saved profiles in the drop down list underneath the processed photos image.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 112

SECTION II
p) Bar-code Support The SYSTEM shall support the following bar codes: Code 3 of 9 (3:1) Code 93 UPCA EAN 13 EAN 8 Code 128 A Code 128 B Code 128 C Codabar

FUNCTIONAL REQUIREMENTS

PostNet (Zip +4 Postal) Code 3 of 9 (2:1) Interleaved 2 of 5 (2:1) PDF-417 (2D) Code 128 Auto UCC-128 MSI Plessey Extended Code 3 of 9 Extended Code 93

The SYSTEM shall allow for any database field or ASCII string to be encoded onto the bar-code at the time of printing through an expression editing tool in the software. This shall be a standard feature in the software. q) PIV card import The SYSTEM shall provide the ability to add a contact chip reader to the workstation and to import cardholder information from PIV end point dual interface smart cards (and compatible cards compliant with PIV standards). Imported data shall include at least the following: o FASCN o GUID o DUNS (if it is encoded) o Card Expiration Date o Full Name o First Name o Middle Initial o Last Name o Employee Affiliation o Organizational Affiliation LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 113

SECTION II
o Agency Card Serial Number o Issuer Identification

FUNCTIONAL REQUIREMENTS

r)

On-Line Context Sensitive Help

The SYSTEM shall provide on-line context sensitive help files to guide the System Administrators and System Operators in the configuration and operation of the SYSTEM. The help menu shall be available from any window in the SYSTEM by pressing the F1 function key or clicking on the help icon in the toolbar. Help windows shall be context sensitive so System Operators can move from form to form without leaving the help window. Standard windows help commands for Contents, Search, Back, and Print shall also be available. The SYSTEM shall also come with complete on-line documentation on the product disc.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 114

SECTION II

FUNCTIONAL REQUIREMENTS

5. Digital Video Management (With Lenel Network Video Recorders)

a) Overview The Digital Video Management System (DVMS) shall be available as a standalone solution or as an integrated solution that is seamlessly integrated with other Total Security Knowledge Management Solution Modules, including Access Control & Alarm Monitoring, Asset Management, Credential Management, and Visitor Management. All functionality described from this point forward shall reflect functionality of the seamlessly integrated system. The DVMS shall work in conjunction with a Manufacturer Network Video Recorder (LNVR) The LNVR shall not utilize any multiplexer-type technology for video recording. Information supplied from IP camera sources via Ethernet shall be digitally recorded simultaneously to a LNVR. The LNVR shall support a variety of industry standard IP Cameras from multiple manufacturers. The LNVR shall be available in a Turnkey Solution as well as a Software Only version. In a Software Only version, users shall be able to load the LNVR software onto an industry standard PC platform of their choice, as long as it meets the Manufacturers minimum specifications. The Turnkey Solution shall also be available in a hybrid configuration, allowing for the unit to record video from both IP and analog source video inputs. The analog sources shall be supported by video capture board options: 1) MPEG4: 8-Channel Video Board (up to 2 boards per chassis) which supports 8 channels at 3.75fps (NTSC) at 640 x 240 (640 x 480 interlaced) resolution; or 8 channels at 7.5fps (NTSC) at 320 x 240 resolution. 8 channels at 3.7fps (PAL) at 640 x 240 (640 x 480 interlaced) resolution; or 8 channels at 6.2fps (PAL) at 320 x 240 resolution. 2) MPEG4: 4-Channel 30fps Video Board (up to 4 boards per chassis) which allows simultaneous recording of up to 16 high motion cameras. Each camera may record at 30fps, 15fps, 7.5fps, 2fps, or 1fps (NTSC) and 25fps, 12.5fps, 6.2fps, 2fps, or 1fps (PAL). These can be at 320x240, 640x480 or 720x480. 3) H.264: 16-Channel FULL frame rate High Resolution Video Board, which allows simultaneous recording of up to 16 high motion cameras. Each camera may record at 1/16, 1/8, 1/4, 1/2, 1, 2, 4, 6, 8, 10, 12, 15, 16, 18, 20, 22, 30(NTSC)/25(PAL). Resolutions will support, NTSC: 352*240(CIF), 704*240(2CIF), 528*320(DCIF), 704*480(4CIF); PAL: 352*288(CIF), 704*288(2CIF), 528*384(DCIF), 704*576(4CIF).

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 115

SECTION II

FUNCTIONAL REQUIREMENTS

The LNVR shall be able to store recorded video on any industry standard storage medium, as long as it meets the Manufacturers minimum specification. The user shall be able to choose the appropriate storage medium for their application, such as a hard disk storage array, storage area network, or network attached storage. The LNVR shall provide a fully modular architecture that offers upgrades in-place for additional recording capacity and shall continuously record up to an unlimited number of video sources. The LNVR shall simultaneously record video/audio, display live video/audio, and display recorded video/audio. None of the video operations shall interfere with the other. Recording shall not stop playback, live viewing, or storage of video. The LNVR shall support event-based recording and/or shall record continually 24 hours a day. The amount of local online storage that is available for playback from the LNVR shall be dependant on the size of the hard drive in the LNVR or other storage medium as well as the individual camera configuration (Frame Rate, Resolution, Compression). The LNVR shall support Multicast-streaming technology whereby, once one user has requested a live video stream other system users shall be able to view the same video stream without opening a separate connection. Multicast streaming technology helps limit the amount of bandwidth required for system operation/monitoring. The LNVR shall support Unicast-streaming technology whereby each request for recorded video will require a separate stream. The LNVR shall support the limiting of frames per second to individual clients. This shall be mutually exclusive with the Multicast-streaming technology. While the LNVR is continuously recording or archiving video, an unlimited number of authorized System Operators shall access video from a central archive server from client workstations connected to the data network (via a LAN or WAN connection). Up to 32 simultaneous System Operators shall access live or recorded video from a LNVR. Using a centralized system administration tool, user defined profiles restrict each System Operators security access to specific video and to specific system operations, such as video monitoring, playback, adding, modifying, and deleting cameras. A user-friendly database query tool shall enable authorized System Operators to quickly locate video from any recorder and transparently play it back. The SYSTEM shall enable CUSTOMER to use off the shelf video enhancement software. These image enhancement kits allow the System Operator to enhance a single video capture frame. The single captured frames shall be a copy of the original recorded video. System Operators cannot alter the original recorded video in any way. The LNVR shall come with an image enhancement tool that shall be built into the digital video player (DVP). The design of the LNVR shall be flexible and allow for the following:

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 116

SECTION II

FUNCTIONAL REQUIREMENTS

a. Independent camera setup for frame rate, resolution, compression rate, brightness, contrast and other factor setups. This architecture shall allow System Administrators to optimize camera-recording settings. Each camera shall have the ability to be set to operate with a different frame rate, resolution, compression rate, brightness, contrast and other factor setups. b. Total system solution to enable enterprise-wide, networked, multi-user access to all system resources via a wide range of options for connectivity with the customers existing LAN and WAN. c. Scalable, yet compact system design that offers modular expansion to protect CUSTOMER investment. d. Independent camera setup configurations for pre-event, event, and post-event states shall be available. User shall be able to determine independent frame rate settings for these states. Independent camera setup configurations for time-lapse mode shall be available. e. Independent camera setup configurations for live versus recorded playback shall be available. User shall be able to determine different frame rate settings for live viewing and recorded playback. b) Network Interface The LNVR shall connect to an existing network. Various types of network architectures shall be supported including Ethernet 100BT and 1 Gigabit Ethernet. Various types of network protocols shall be supported including TCP/IP, IPX, and UDP. The network interface shall allow remote access of the recording system from various System Configuration and Alarm Monitoring client workstations located throughout the customer's facility. Playback Over the LAN/WAN The LNVR shall be configured to playback stored video over the LAN/WAN for remote access of video clips.

c) Seamless Integration with Total Security Knowledge Management Modules 1) Seamless Integration with Access Control and Alarm Monitoring The LNVR shall seamlessly integrate with the Access Control & Alarm Monitoring System. Any alarm/event in the SYSTEM shall have the ability to be associated with a digital video clip in real time. Each alarm/event in the SYSTEM shall store a pre-defined number of seconds of video before the event occurred and a pre-defined number of seconds of video after the event occurred. This video clip shall be retrieved at any system Alarm Monitoring client workstation.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 117

SECTION II

FUNCTIONAL REQUIREMENTS
The same database MUST store information from both the LNVR and the Access Control & Alarm Monitoring System. A separate database for the two systems is unacceptable. 2) Seamless Integration with Asset Management The LNVR shall seamlessly integrate with the Asset Management System. Any asset alarm/event in the SYSTEM shall have the ability to be associated with a digital video clip in real time. Each alarm/event in the SYSTEM shall store a predefined number of seconds of video before the event occurred and a pre-defined number of seconds of video after the event occurred. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the LNVR and the Asset Management System. A separate database for the two systems is unacceptable. 3) Seamless Integration with ID Credential Management The LNVR shall seamlessly integrate with the ID Credential Management System. Any ID Credential Management or cardholder alarm/event in the SYSTEM shall have the ability to be associated with a digital video clip in real time. Each ID Credential alarm/event in the SYSTEM shall store a pre-defined number of seconds of video before the event occurred and a pre-defined number of seconds of video after the event occurred. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the LNVR and the ID Credential Management System. A separate database for the two systems is unacceptable. 4) Seamless Integration with the Visitor Management The LNVR shall seamlessly integrate with the Visitor Management System. Any Visitor Management cardholder alarm/event in the SYSTEM shall have the ability to be associated with a digital video clip in real time. For each Visitor alarm/event in the SYSTEM shall store a pre-defined number of seconds of video before the event occurred and a pre-defined number of seconds of video after the event occurred. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the LNVR and the Visitor Management System. A separate database for the two systems is unacceptable.

d) Manufacturer Network Recorders The Manufacturer Network Video Recorder (LNVR) main storage medium shall be a digital hard drive. All video information can be stored on the LNVR internal hard drive for immediate playback. The hard drive shall work in a FIFO (First In First Out) mode to allow new video clips to overwrite old clips. The LNVR shall be able to be configured to LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 118

SECTION II

FUNCTIONAL REQUIREMENTS

only store video for a user definable number of days. Any recorded video older then the user defined number of days shall not be available for either play back or viewing. The system shall support the use of local RAID 5 storage subsystems, which connect directly to the LNVR via RAID Controller Card. The system shall support the use of the Nexsan ATAboy 2 (IDE/ATA Drives) unit, Nexsan SATABoy (iSCSI/SATA Drives), Nexsan SATABeast (Fibre/SATA Drive). In all cases, initial system configuration shall take place via the respective third party software. However, system function thereafter shall be seamless to the user. The LNVR shall communicate with the SYSTEM Alarm Monitoring and System Administration client workstations over the CUSTOMER network or a private security network. The LNVR shall support networks such as Ethernet and over TCP/IP, IPX, and UDP protocols. The LNVR shall record camera signals from fixed color and fixed black & white cameras, dome, infrared cameras, x-ray cameras, and low light cameras. Each LNVR shall have the ability to be given a realistic name of up to 32 alphanumeric characters and shall have the ability to be marked on-line or off-line. Each LNVR shall be given a workstation name as well as an IP address of where the LNVR is connected to the network. Each LNVR shall also have a World Time Zone setting to allow LNVR to reside in different areas of the world. Should the LNVR go offline, a specific alarm will be sent to Alarm Monitoring. Furthermore, a red X will display over the LNVR icon in the system status tree. Once the LNVR is brought back online, the red X shall no longer display. The SYSTEM shall allow an operator to view the available storage and performance information directly from the configuration of the camera. This shall include the available storage, resource usage and recording rates for the network video recorder. Threshold alarms shall also be configurable when the amount of available storage falls below a set number of days. The Turnkey LNVR shall be available in the following configurations: 1) LDVR/UVS Extended Storage Chassis (DVC-EX1), shall include 3U, 19-inch rack mount chassis with Intel P4 3.0GHz single core CPU, 1GB 533MHz RAM, Windows XP Professional operating system, Dual 10/100/1000 Ethernet ports, one 80GB OS only hard drive, UP TO 8 data hard drives KIT OPTIONS AVAILABLE, DVD/CD ROM, mouse and rack mount rail kit. 2) Premium Extended Storage Chassis (DVC-EX2), shall include 3U, 19-inch rack mount chassis with Intel Core 2 Duo E8400 3.0GHz dual core CPU, 2GB 667MHz RAM, Windows XP Professional operating system, Dual 10/100/1000 Ethernet ports, one 80GB OS LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 119

SECTION II

FUNCTIONAL REQUIREMENTS
only hard drive (UP TO 8 data hard drives KIT OPTIONS AVAILABLE), DVD/CD ROM, mouse and rack mount rail kit. 3) LNVR Low Profile Storage Chassis (DVC-1U), shall include 1U rack mount chassis with Intel Xeon x3230 2.66GHz quad core CPU, 2GB 533MHz RAM, Windows XP Professional operating system, Dual 10/100/1000 Ethernet ports, one 80GB OS only hard drive (UP TO 3 data drives KIT OPTIONS AVAILABLE), CD/RW-DVD/R, mouse and rack mount rail kit. 4) 2U Standard Chassis (DVC-2U), shall include 2U, 19-inch rack mount chassis with Intel Celeron D E1400 2.0GHz dual core CPU, 1GB 667MHz RAM, Windows XP Professional operating system, 10/100/1000 Ethernet port, one 80GB OS only hard drive (UP TO 4 data hard drives KIT OPTIONS AVAILABLE), DVD/CD ROM, mouse and rack mount rail kit.

e) Digital Video Cameras 1) Individual Camera Input Setup Each digital video camera or video encoder shall be independently configured to record digital video. Each camera shall have the ability to be given a realistic name of up to 32 alphanumeric characters and shall allow for the setup and adjustment of brightness, contrast, archiving, motion detection, Pan/Tilt/Zoom, on a per camera basis. The SYSTEM shall recognize the LNVR and channel that the camera is connected. System Administrators shall define whether each camera allows Pan/Tilt/Zoom commands to be accomplished from the Digital Video Player. The LNVR shall support multiple network enabled Video Cameras and Video Encoders. The Video Encoder technologies shall allow the LNVR to interface with analog and PTZ cameras. The LNVR shall support the following video formats simultaneously on the same system: 1) MJPEG 2) MPEG-4 3) H.264 The LNVR shall support both formats simultaneously on the same system. The LNVR shall support multiple video resolutions in both NTSC and PAL configuration. These resolutions will include CIF (352 x 240 NTSC or 352 x 288 PAL), 4CIF (704 x 480 NTSC or 704 x 576 PAL), D1 (720 x480 NTSC or 720 x

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 120

SECTION II

FUNCTIONAL REQUIREMENTS
576 PAL), VGA (640 x 480) and mega-pixel resolutions. These resolutions shall be dependent on the network enabled video device. Each camera and video encoder shall have recording settings to customize the recording properties of the camera including: 1) Compression The compression of video input used by the particular encoder (MJPEG, MPEG-4, H.264) depending on camera type. 2) Resolution The size of the image expressed in pixels. (example: 320 x 240, 640 x 480) This shall depend on the type of camera or video encoder. 3) Frame rate The number of frames per second the network enabled video camera or video encoder transmits a video stream to the LNVR. 4) Pre-Roll - The number of seconds of video that the LNVR will store previous to the event time that a linked event is generated. This time is specific to the associated event. The SYSTEM shall support up to 900 seconds of pre-roll. 2) Post-Roll - The number of seconds of video that the LNVR will store after a linked event is generated. This time is specific to the associated event. 2) Generate Motion Detection Alarms If supported by the camera or video encoder, each camera or video encoder shall have the ability to record video to the LNVR based on motion detection at the camera or video encoder. The times that motion detection recording occurs shall be user defined by time-zones. A sensitivity bar shall be available to adjust the sensitivity for motion in the cameras. If supported within the camera or video encoder, each camera shall have the ability to have a separate time zone and motion detection settings if desired. Areas of the video picture shall be configured to detect motion. Motion in these areas shall generate alarms. 3) Time-Lapse Recording The LNVR shall allow the ability to configure time-lapse recording on a by camera or video encoder basis. System Administrators shall have the ability to configure cameras or video encoder to record one frame of video every (x) seconds (2-3600 seconds) when there is no motion in the viewing area. Once motion is detected, the LNVR shall automatically increase recording rate to a predefined frame rate, or can simply always record at the time-lapse rate. The LNVR shall also be able to use an event from other integrated SYSTEM modules to start recording at the increased frame rate.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 121

SECTION II
4) Audio Support

FUNCTIONAL REQUIREMENTS

The LNVR shall support unidirectional and, if supported by the camera or video encoder, synchronized audio recording through cameras or video encoder that support this option. The ability to record synchronized audio and video shall be enabled through and stored in the LNVR. The audio shall be available for both recorded video and live video playback. The audio shall be exclusively available for recording purposes. The SYSTEM shall only support audio protocol G.711. 5) Firmware downloads Select cameras and video encoders shall have the ability to receive automatic firmware downloads. These automatic firmware downloads shall be scheduled through the use of the SYSTEM Scheduling mechanism. 6) Dry Contacts The LNVR shall support both inputs and outputs that are provided by cameras or video encoder. The LNVR shall monitor the cameras inputs and upon state change, shall report an alarm to the SYSTEM. Outputs shall be available for linkage through the Global I/O feature of the SYTEM. These outputs shall also be able to be triggered by the System Operator through alarm monitoring. 7) Camera Storage Support Depending on camera/encoder capabilities, IP cameras and IP video encoders shall be able to utilize internal or external storage areas to reduce and schedule bandwidth usage between the camera and the LNVR. System Users shall be able to use camera memory to record video-based on internal motion detection events, this video shall then be transferred from the camera to the LNVR during a scheduled Time zone. This shall not prevent live video from being viewed from the camera on demand by the System Operator. The System Operator shall also be able to request to view video that has yet to be transferred and is still on the cameras memory. This information shall be presented as if it was recorded on the LNVR. 8) MJPEG to MPEG-4 Conversion The LNVR shall allow System Operators the ability to change compatible cameras from MJPEG to MPEG-4 while preserving the pre-established link setup on that camera. 9) User Permissions for Viewable Cameras The SYSTEM shall allow System Administrators to limit the maximum number of viewable camera channels for a User. 10) Support for RTP Protocol The SYSTEM shall support Real-time Transport Protocol (RTP) working in conjunction with RTSP. The System Operator shall be able to configure the system to receive video LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 122

SECTION II

FUNCTIONAL REQUIREMENTS

from RTP-enabled cameras. The following methods are supported by the SYSTEM: RPT via Multicast, RTP via RTSP, RTP via RTSP via HTTP, and RTP via UDP/IP. f) IP Based Camera Video Surveillance The LNVR offers CUSTOMER an IP-based video surveillance only solution. The LNVR shall allow for camera and video encoder configuration and viewing of live video from industry standard IP cameras and IP encoders via the System Administration and Alarm Monitoring applications. The LNVR software shall be loaded on the SYSTEM Access Control/Security Server to allow for the seamless integration of SYSTEMs Total Security Knowledge Management product suite with industry standard IP surveillance products. Customers shall be able to view video from many cameras simultaneously and only limited by frames per second, image resolution, compression, network bandwidth and client PC capabilities. The system shall support the use of IP based camera and IP encoder hardware for live (surveillance only) viewing through the Alarm Monitoring Application. The viewing of live video from these cameras/encoders via the Alarm Monitoring Module shall be seamless to the System Operator. Each IP camera/encoder shall be assigned a unique IP address so that users can use the SYSTEM to configure, view, and administer each camera/encoder individually. IP cameras/encoders shall be treated exactly the same as their analog counterparts except as noted below. IP cameras /encoders shall be accessed directly from an embedded web server page located within the camera/encoder. Access shall be by device IP address. Local camera/encoder authentication shall be enforced to prevent unauthorized access. Recording rates shall be equal to or less than the live video frames per second (FPS) rate setting and shall stream from the LNVR unless the recorder is removed by network fault for a time period specified by the administrator after which live video may be automatically streamed directly from the camera for live viewing at a client workstation within the same network subnet. g) IP Camera Discovery Utility The SYSTEM shall provide an IP Camera Discovery Utility (UTILITY) for searching and discovering IP cameras on a network, specifically for the purpose of identifying the IP cameras IP addresses. The UTILITY shall discover devices in the local subnet as well as across the multiple subnets configured on the network. The UTILITY shall be able to search and discover cameras produced by at least three (3) different camera manufacturers. h) Device Linkages The LNVR shall seamlessly integrate with the Access Control & Alarm Monitoring System. Each access control field hardware device that is configured in the SYSTEM may be configured to be linked with a camera/encoder from the LNVR. A LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 123

SECTION II

FUNCTIONAL REQUIREMENTS

camera/encoder shall have the ability to be linked with multiple access control hardware devices and an access control hardware device shall have the ability to be linked with multiple cameras/encoders. An unlimited number of access control hardware/device links shall be configurable. A video viewing priority shall be given to each access control hardware device link. In the event that multiple cameras/encoders linked to a single access control hardware device generate an alarm, the camera/encoder with the higher priority will show in the Alarm Monitoring Video Window first, followed by cameras/encoders with lower priority. Each alarm/event condition shall have the ability to mark the start of a video event or the end of a video event in real time. For example, when a door forced open is activated, the LNVR can mark the start of the video event. When the door forced open restored alarm occurs, the LNVR can mark the end of the video event. For alarms that mark the start of the video event, a default Video Event Timeout shall be available that will end the video event in the case that a restored alarm does not occur or if there is no restored alarm for the event. System Administrators shall have the option for each alarm/event to automatically launch the Digital Video Player at the Alarm Monitoring client workstation when an alarm or event is generated. If an alarm is configured to automatically launch the Video Player, the system operator can configure it to launch recorded video in addition to live video. This functionality must be configured on each Alarm Monitoring workstation. The LNVR shall support device linkage configuration setup wizard to guide System Administrators through the configuration of the device-camera/encoder links. The setup wizard shall guide System Administrators step by step by asking a series of questions that, when answered, will allow the LNVR to automatically configure device-camera links. i) Purging Each LNVR shall have the ability to be configured for purging locked video events instead of archiving. In that case, the Archive Server shall simply purge events from that LNVR rather than transfer them to the storage volume. Event locking and purging is available for all LNVRs. j) Video Viewing Layouts The Digital Video Management System (DVMS) shall provide a user the ability to save the list of camera/encoders currently being played along with the currently selected template, if one is selected, under a layout name provided by the user. The DVMS shall allow for user created layouts, single view, matrix view, and other preconfigured layouts to loaded as desired by the System User.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 124

SECTION II
k) Browser Based Video Viewer

FUNCTIONAL REQUIREMENTS

The SYSTEM shall provide a browser based video viewer option. The SYSTEM shall automatically download and install any required components directly onto the browser. The browser based video viewer shall have the ability to select multiple view templates. This browser based video viewer shall provide the following functionality: 1) Ability to be loaded on a PC through a web browser with minimal effort 2) Authenticate through a SYSTEM user account 3) Only SYSTEM authenticated users shall be able to access the video over the HTTP protocol 4) Be limited to only viewing/controlling such video as has been allowed by the SYSTEMs user permissions 5) Ability to view live and recorded video 6) Log user transactions for accessing of video (Who, When, What video segments, PTZ) 7) Display live and recorded video from any supported DVR or NVR 8) Receive live video from LNVR over firewall friendly HTTP or HTTPS protocol 9) Ability to view live video from a multiple number of channels over HTTP 10) See live video from cameras that support MPEG-4/MJPEG/H.264 format 11) Ability to perform seeking operations on the recorded video a) Ability to perform seeking using the seeking slider bar, including goto start b) Ability to change start/end time of the displayed video clip on the fly c) Ability to change playback speed using controls d) Ability to synchronize selected camera cells to a single control interface 12) Ability to listen to the audio stream over the HTTP protocol 13) Digital zooming/panning 14) PTZ camera control a) Relative Mode (Drag or double-click-to-center)

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 125

SECTION II

FUNCTIONAL REQUIREMENTS
b) Mixed Mode (continuous or click-to-center) c) Continuous Mode (click and hold to move) 15) Click to center 16) Export video 17) Monitor zones 18) Ability to access video from multiple recorders The browser based video viewer shall use an N-tier architecture. Browser based video viewer requires the use of Internet Explorer 6.0 or 7.0 and 1024x768 resolution. 19) Limit the number of cameras a user is permitted to view 20) Browser Based PTZ Locking When a System User selects a cell that contains a PTZ camera the SYSTEM shall attempt to lock it to eliminate another System User with lower priority from taking control of the camera. To allow a System User with lower priority to use the PTZ camera the initial System User must unlock the PTZ camera.

l) Alarm Monitoring The LNVR shall seamlessly integrate with the SYSTEM Alarm Monitoring Module. Upon generation of an alarm that is configured to mark video, the System Operator shall be able to recall the video segment associated with the alarm. Once launched, the System Operator shall have the ability to adjust the start and end time of the segment. The SYSTEM Alarm Monitoring Module shall be able to save the list of video windows, the video windows sizes, the video windows locations, and the all the selected camera options under a System Operators profile. The next time the System Operator runs Alarm Monitoring the same list of video windows, the video windows sizes, the video windows locations, and the all the selected camera options shall be automatically launched. 1) Real Time Monitoring The LNVR shall allow monitoring of real time video from any Alarm Monitoring client workstation. The System Operator shall be able to monitor any camera by using the System Hardware Status Tree and choosing the appropriate camera. Output of video for real time monitoring shall be transferred to an Alarm Monitoring client workstation over the LAN/WAN. In the LNVR, authorized System Operators shall be able to concurrently playback recorded video from any clip, even as that video clip is being recorded. The Play LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 126

SECTION II

FUNCTIONAL REQUIREMENTS
button shall enable System Operators to play back a single video segment at the maximum recording configuration. The LNVR has an integrated Matrix View which shall enable viewing of Live and Recorded streams simultaneously. The Maximum displayable frames on a given client PC shall be determined by the resolution, compression, video type and PC specifications of the client machine. Benchmark data will be made available. The SYSTEM shall monitor the firmware revision of the LNVR as well as hard drive space percentage used. The DVMS shall support the automatic upgrade of firmware through the use of the SYSTEM scheduling mechanic. 2) Double Video On Alarm The SYSTEM shall support the ability to have a SYSTEM event/alarm trigger associated video to be displayed in two distinct cells. There shall be one cell for the live video and one cell for a recorded stream. The recorded stream shall be able to be configured to pause at alarm time or playback the pre-roll data. This shall be configured on a per alarm basis. 3) Multi-Camera Alarms The LNVR shall provide the ability to launch more then one camera on a triggered alarm if the device that triggered the alarm is monitored by more then one camera, When the alarm is generated the DVMS shall launch a video window for each camera associated with the triggered device. 4) Playback Control The LNVR Playback Control shall offer the following features for full System Operator control of video playback: a) Start and Stop Playback During operation of the viewer application, the authorized System Operator shall be able to start and stop playback. This operation shall not affect any other operation. b) Pause and Resume During playback of video, the System Operator shall be able to pause and resume current playback. This operation shall not affect any other operation. c) Fast Forward During playback of video, the System Operator shall be able to use the Fast Forward button to view the playback at faster than normal speed. This operation shall not affect any other operation.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 127

SECTION II
a. Skip Backward

FUNCTIONAL REQUIREMENTS

During playback of video, the System Operator shall be able to use the Skip Backward button to rewind the playback. This operation shall not affect any other operation. d) Frame Advance During playback of video, the System Operator shall be able to use the Frame Advance button to advance the video clip one frame at a time. This operation shall not interfere with any other operation. The System Operator shall also have the ability to switch between other cameras if the device that generated the event has more than one camera associated with it. The System Operator shall have the ability to adjust the start and end times of the video segment once the video segment is displayed. The System Operator shall also have the ability to adjust the playback speed of the video segment from slower than normal to real time to high speed playback. The System Operator shall have the option to switch to Live Mode from a camera at any time during the operation. The System Administrator shall also have the ability to load any video file from a backup device into the digital video player at any time. The digital video player shall be user configurable to show the date and time of the video clip frame, as well as the current mode of the player (play or live). The System Operator shall have the ability to display or not display the informational text. The digital video player shall also have the option to automatically launch upon a critical alarm occurring in the SYSTEM to show live video at the video camera linked to that hardware device. 5) Video Player The Video Player shall support an advanced Matrix View of On-line camera views. The frame rate limitation shall be any combination of live or recorded video. The number of video streams in the matrix is dependent on the frame rate and resolution of the cameras/video clips being requested and the hardware of the client viewing PC. Benchmark data must be available from the manufacturer on select PC platforms. The Matrix view shall allow the sizing of the matrix windows. 6) Two-Way Audio The Alarm Monitoring client shall support a dialog that will enable audio communication to and from audio enabled IP video sources. The user shall be able to manually send voice or saved audio files to the audio enabled IP video LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 128

SECTION II

FUNCTIONAL REQUIREMENTS
source to be played through the devices speaker. The users shall also be able to hear audio from the audio enabled IP video sources microphone. The SYSTEM shall only support audio protocol G.711. 7) Pan/Tilt/Zoom Control from Alarm Monitoring The LNVR shall support pan/tilt/zoom (PTZ) controls from the Alarm Monitoring Workstation using a PC mouse, USB direct play controller device (joystick) or RS-485 device. The PTZ control shall be supported in conjunction with IP PTZ cameras. Supported command settings shall be available for: 1. Pan Left 2. Pan Right 3. Tilt Up 4. Tilt Down 5. Zoom In 6. Zoom Out 7. Focus Near 8. Focus Far 9. Iris Open 10. Iris Close 11. Go to Preset 12. Stop PTZ Movement

8) Addition Pan/Tilt/Zoom Features The DVMS shall support the use of pan/tilt/zoom (PTZ) security and priority levels. The following features outline the increased security to the Digital Video PTZ control. a) Priority Levels The DVMS shall support priority levels used in conjunction with PTZ control. The DVMS shall contain a user friendly check box system to denote a System Operators ability to control PTZ cameras. The DVMS shall also contain an edit box that will allow the System Administrator to assign PTZ priority levels. These two features shall be used to allow only System Operators with the appropriate permission levels the ability to take control of PTZ cameras. b) Device Group Control The DVMS shall provide the ability for System Administrators to limit the System Operators access to certain camera device groups. c) PTZ Override Control The DVMS shall allow a System Operator who is controlling a PTZ camera the ability to temporarily lockout other System Operators, with lower priority levels, from controlling the same PTZ camera. The DVMS

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 129

SECTION II

FUNCTIONAL REQUIREMENTS
shall also provide a timeout feature that will unlock the PTZ after a System Administrator assigned amount of inactivity. d) Proportional PTZ Control The DVMS shall provide PTZ control that is proportional to the view of the camera. This proportional control shall take the current zoom position into account. For example, if the camera is zoomed in, a mouse click will cause a slower movement then if the camera was zoomed out and the same mouse click occurred. e) Matrix View PTZ Accessibility The DVMS shall allow System Operators the ability to double click on a single video in matrix mode to launch a new single video window. The new window shall have PTZ enabled automatically. f) Preset Alarm Actions The DVMS shall store the priority level of the System Operator who creates the preset alarm action and will use that priority when issuing the go to preset PTZ command. g) System User Configured Presets The DVMS shall allow System Operators the ability to record the current PTZ location, absolute, pan, tilt, and zoom positions, under a user defined name. The System Operator will then be able to bring up the preset camera location by selecting the user defined name from a drop down list. h) Preset Tour The DVMS shall support the ability to record a set of PTZ commands and save them under a user-definable tour name. The System Operator will then be able to select the tour name to have these commands repeated at a future point in time. The DVMS must be able to record the order of each command as well as the timing of each command. The DVMS shall be able to conduct multiple Preset Tours without client applications running through the use of a dedicated service to control the tours. 9) Video Camera Groups/Video Camera Tours The DVMS shall support camera grouping to allow for video camera tours to occur in the SYSTEM Alarm Monitoring Module.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 130

SECTION II

FUNCTIONAL REQUIREMENTS
An unlimited number of camera groups shall be supported in the SYSTEM and each camera group shall support an unlimited number of cameras. Cameras within a camera group shall span multiple Digital Video Recorders. Cameras shall have the ability to be placed into multiple camera groups. Once grouped, the System Operator shall be able to start a video camera tour that shall rotate live video between each of the cameras defined in the video camera group at a user defined increment. The time increment between switching cameras shall be user definable in one second increments. 10) Still Image Capture During playback or monitoring of video, the System Operator shall use the Pause button followed by selecting Enhance Image from the Options Menu to create a still picture. This operation shall not affect any other operation and shall not alter the recorded video. 11) Still Image Save The captured image Export button shall allow System Operators to save single video frames to the client workstation hard drive in a standard file format. The System Operator shall be able to later e-mail, print, or transfer the file to any other media. 12) Export Video Clip to File The System Operator shall have to ability to save and export recorded video to a file for the purpose of sharing and reviewing video clips. The start and end times for each video segment shall be determined by the System Operator. The exported video clip shall be viewable via a standard Windows media player or via a video player provided by Manufacturer. Optional Time, Date Stamp, and User Defined text shall be able to be overlaid onto the video during export using an optional transparency level. 13) Video Image Processing The DVMS shall support video image processing of a single frame captured image through use of an image processing module. The image processing module shall show both the original captured image side by side next to the processed image. The following effects shall be available to System Operators to apply to an original captured image in any combination desired: 1) Intensity - Increases or decreases the overall intensity level of the light in the image. Adjusts the brighter areas by making them brighter or darker. 2) Contrast - Increases or decreases the range of gray levels contained in the image. It adjusts the distinction between the lightest and darkest tones in the image. LENEL - A UTC FIRE & SECURITY COMPANY

OnGuard

Functional Specifications Version 6.3 Series

Page 131

SECTION II

FUNCTIONAL REQUIREMENTS
3) Saturation - Adjusts the purity of color (the number of colors used to create a particular color). 4) Gamma Correct - Enhances detail in the image by adjusting the middle tones without affecting the darkest and lightest areas. 5) HistoContrast - Adjusts the number of pixels per gray level to create a linear relationship between gray levels, used to bring out the detail in dark areas of the image. 6) Hue - Adjusts the main characteristic of a particular color that distinguishes it from other colors. 7) HistoEqualize - Redistributes shades of colors to adjust imbalances. It makes the darkest colors black and the lightest colors white and stretches the colors in-between. 8) Flip - Flips the image horizontally (the image will appear upside down). 9) Reverse - Flips the image vertically, creating a mirror image of the original. 10) Rotate - Rotates the image 0-360 degrees. 11) Shear - Applies the look of three-dimensionality to the image, while maintaining the original size and shape. 12) Add Noise - Creates a granular effect that adds texture to a flat or overly blended picture. 13) Average - Converts each pixel in the image to the average of itself and the pixels to the right and bottom, resulting in a blurring of the image. 14) Sharpen - Enhances the edges and brings out the detail. 15) Halftone - Converts the image to a black and white (1 bit/pixel) image in which different shades of gray (luminance) are represented by different patterns of black and white pixels. 16) Median - Reduces the amount of graininess (noise) in an image. 17) Emboss - Converts the image to a raised relief style with its light source directed from the top left. 18) Gray Scale - Represents the image using up to 256 shades of gray. 19) Invert - Inverts the colors in the image as on a photographic negative. 20) Mosaic - Converts the image to a grid of square blocks of color. 21) Posterize - Reduces the color resolution, which is the number of shades of color that shall be displayed simultaneously.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 132

SECTION II

FUNCTIONAL REQUIREMENTS
The DVMS shall allow for the System Operator to save any combination of effects as a profile to be used on other still images for image processing. Profiles shall have the ability to be added or deleted from the SYSTEM at any time. 14) Resizable Video Window Function During playback or monitoring of video, the System Operator shall be able to enlarge the size of the video screen to twice the recorded resolution to have video display larger on the monitor screen. This operation shall not affect any other operation. The USER shall have the option to monitor the video at any user specified size with out maintaining aspect ratio. 15) Video Validation The LNVR shall detect video loss from any or all cameras. If a camera stops transmitting video or the BNC cable from a camera to the video recorder is disconnected or malfunctions, the video recorder supervision shall detect the video loss and will alert the System Operator via the alarm monitoring client workstation window, audible alarm, visual alarm, or pager can be optionally set. 16) Dual Path Failover and Redundancy The LNVR shall support the ability to configure a second location (or path) for an IP camera or IP encoder to failover in the event that the primary LNVR fails. For example, if the system is comprised of two 16 channel LNVRs and one of the LNVRs should fail, the cameras that normally record to it will failover and begin recording to the second LNVR. This failover will be seamless to the System Operator. The failover shall occur in less than 60 seconds from the time the primary recorder goes offline, thus minimizing the loss of video during the failed condition. The second location may also be configured as a redundant recording location. In this mode two (2) copies of the video data will exist, one at each location. In the event of a primary recorder failure, the SYSTEM shall automatically route video from the appropriate source to any open client connections without user intervention. This shall work for Live and Recorded video playback. Channel alarms such as Motion Detection will be masked from the secondary recorder unless the primary recorder fails. Alarms from the secondary recorder will be visibly marked as secondary recorder alarms. 17) Analog PTZ Camera Support via IP Encoders Units The LNVR shall integrate the video encoders ability to support a specific set of analog PTZ cameras. These analog cameras are converted to digital using the video encoders and are then controlled in the same method as other IP/Network cameras in the system.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 133

SECTION II
18) Presets on Alarm

FUNCTIONAL REQUIREMENTS

The LNVR shall integrate presets that are called based on alarm conditions. Each event/alarm in the SYSTEM shall be able to be assigned to a preset on the camera. The DVMS shall have the ability to record video based on motion detection of the camera. The times that motion detection recording occurs shall be user definable on a time zone basis. Each camera shall have the ability to have a separate time zone and motion detection settings if desired. Areas of the video picture shall be configured to monitor motion. Motion in these areas shall generate alarms. 19) Event Locking The LNVR shall have a clip-lock option to prevent overwriting of specific video clips regardless of their date and time. Each event/alarm in the system has the ability to be locked and/or unlocked by appropriately permissioned users. 20) UNC Path Support The LNVR must be able to support Network Attached Storage Devices/Storage Architecture. This means for the storage path, you must be able to input a UNC path to write to instead of a hard drive letter. 21) Blind Camera Alarm The LNVR shall support the blind camera alarm. If for example, someone places something over the lens of the camera, the SYSTEM shall generate a blind camera alarm in Alarm Monitoring. 22) Configuration of Off-line Cameras The System Administrator shall be able to mark a camera offline by marking a check box in the camera configuration tab. Access to this feature shall be based on System Administrator privileges, username and password. The ability of generating a report on the time, camera, recorder, and user who marked a camera offline shall be supported. 23) Video Capture On Event The DVMS shall support the ability to capture (record) video only when an event occurs. The System Administrator shall be able to configure devices to trigger the recording of events. The event shall be trigged by either camera inputs, cameras motion detection, or other events configured within the SYSTEM. 24) Camera Time Stamps

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 134

SECTION II

FUNCTIONAL REQUIREMENTS
The LNVR, by default, must provide time stamps at the time the video is received. This shall enable the use of time stamps generated by the camera for other purposes. 25) Automatic IP Camera password change

The DVMS shall support the ability for automatic changes to the passwords for both IP cameras and IP encoders. 26) Optionally set the Browser-Based Video Viewing Client to be Default Player The DVMS shall support the ability to choose whether the standard player interface included in the main Alarm Monitoring client or the Browser-Based video viewing client is the default. If the browser based video viewing client is the default, when launching video from the main Alarm Monitoring client, a browser will be launched and capable of automatically logging in a displaying the requested video through the browser.

m) Intelligent Motion Video Searching The DVMS shall support advanced automated motion video searching against prerecorded video. The automated motion video search shall analyze frames in a preconfigured video segment polygon to detect motion activity from image to image. It shall display thumbnail images of the frames with activity, complete with a histogram depicting the relative amount of activity within each frame. System Operators shall be able to perform this search by selecting a specific camera and a specific time period in which the suspected activity took place. The DVMS Search Mechanism shall then locate all motion events associated with that camera and time period and display them in trace format or by thumbnail format. The System Operator can then select the event or thumbnail and the system shall automatically begin playing the motion event. The System Operator shall then be able to view each of the individual events through the camera video window. n) Video Export The DVMS shall be able to export user selected video clips to the industry standard .ASF format for viewing in industry standard video viewers such as Microsoft Windows Media Player format. The System Operator shall be able to add text to the clip as well as be able to modify the color, size and position of the font. The System Operator will be able to position the time/date stamp as well as modify the color, and size of the font. The video clip may be sent via email, burned to disc or stored on a directory. The recipient will have the ability to view video without the need for having the SYSTEM Client software installed on their PC machine.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 135

SECTION II
o) Remote Monitor

FUNCTIONAL REQUIREMENTS

The DVMS shall support a Remote Monitoring Application (RMA). The RMA shall be able to be run from any computer, The SYSTEM shall not be required to be installed on the computer using RMA. System Operators shall be able to configure the RMAs in the SYSTEM and use the Alarm Monitoring component to send them video requests. The RMA shall also provide the following functionality: A redistributable Remote Monitoring application must be installed on each Remote Monitoring computer to utilize the Remote Monitoring functionality. Remote Monitor shall support the ability to run multiple sessions on a single computer. These sessions shall have the option of being defined to represent each physical monitor on the Remote Monitor PC. A Remote Monitor session shall be distinguished by the port it communicates to a monitor. Each Remote Monitor session shall be independently controlled from the Alarm Monitoring application. The System Operator shall be able to configure Remote Monitors (RMs) and Remote Monitor Groups (RMGs) in System Administration The System Operator shall have the ability to view RMs and their status in the Alarm Monitoring system hardware tree, as well as in the device group view in case RMGs are defined The System Operator shall be able to view the status of the Remote Monitor Cells (RMCs) under the RM items in the system hardware tree. The System Operator shall be able to drag and drop cameras onto the RM and RMG icon. This will start the live video playback on the RM (or all RMs in a RMG) The System Operator shall have the ability to drag and drop alarms, with associated video onto the RM or RMG icon. This will start the recorded video playback for all the cameras associated with that alarm. The System Operator shall be able to send matrix mode, camera selection, and video playback commands to the RMSRMA via RMs context menu. In the system hardware tree or device group view. Also this menu shall allow System Operators to remove all RMCs from the RM, as well as re-synchronize the RMA (by sending a download database command) The System Operator shall be able to send video playback commands to the RMA via the RMCs context menu in the system hardware tree. This menu also shall allow the user to remove the current RMC, as well as select it when in single player mode The System Operator shall the ability to launch the Local Monitor Window (LMW) by right clicking on the RM or RMC and selecting launch video. Matrix mode, camera selection, and video playback commands performed in the LMW will be also sent to RMA. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 136

SECTION II

FUNCTIONAL REQUIREMENTS

The System Operator shall be able to configure the Remote Monitor to run in full screen mode. The System Operator shall be able to load saved video layouts directly to a Remote Monitor Instance. The System Operator shall be able to select various Video Quality Enhancement (VQE) algorithms that will improve the viewing quality of specified video channels on the client viewing station. The System Operator shall be able to select the "Fog Removal" algorithm. The System Operator shall have improved video as fog in the foreground shall be diminished. The System Operator shall be able to select the De-Interlacing algorithm and the artifacts affects of compression and interlacing shall be diminished. The System Operator shall be able to select the sharpen algorithm and a camera view which is blurred shall be diminished. The impact on the above three VQE algorithms shall only impact the workstation in which the changes were made and shall not impact recorded video or other workstation viewing of the video.

To ensure recorder security, Operator credentials for the video recorders shall NOT be broadcast to the remote monitors. The Alarm Monitoring application will need to be run under the account that has access to all of the video recorders. p) Video Authentication The DVMS shall provide imbedded authentication of video. The video shall be watermarked with an authentication key/signature during the recording of live video to a hard drive. The video player shall have the ability to then verify the videos authenticity during playback. The authentication shall provide the recorder name, camera name, video time, and user information. The authentication shall be able to be password protected. q) On-line Context Sensitive Help The DVMS shall provide on-line context sensitive help files to guide the System Administrators and System Operators in the configuration and operation of the DVMS. The help menu shall be available from any window in the DVMS by pressing the F1 function key or clicking on the help icon in the toolbar. Help windows shall be context sensitive so System Operators can move from form to form without leaving the help window. Standard windows help commands for Contents, Search, Back, and Print shall also be available. The DVMS shall also come with complete on-line documentation on C

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 137

SECTION II

FUNCTIONAL REQUIREMENTS

6. Digital Video Management (With Lenel Digital Video Recorders)

a) Overview The Digital Video Management System (DVMS) shall be available as a standalone solution or as an integrated solution that is seamlessly integrated with other Total Security Knowledge Management Solution Modules, including Access Control & Alarm Monitoring, Asset Management, Credential Management, and Visitor Management. All functionality described from this point forward shall reflect functionality of the seamlessly integrated system. The DVMS shall not utilize any multiplexer-type technology for video recording. Information supplied from camera sources shall be digitally recorded simultaneously to a Digital Video Recorder (LDVR). The DVMS shall support Digital Video Recorders from multiple manufacturers. The DVMS shall provide a fully modular architecture that offers upgrades in-place for additional recording capacity and shall continuously record up to an unlimited number of video sources. The DVMS shall simultaneously record video, display live video, and display recorded video. None of the video operations shall interfere with the other. Recording shall not stop playback, live viewing, or storage of video. The DVMS shall support event-based recording and/or shall record continually 24 hours a day. The amount of local online storage that is available for playback from the LDVR shall be dependant on the size of the hard drive in the LDVR. During the operation of the SYSTEM, specific times shall be marked as an event, such as motion detection. This marked video shall be available for playback and/or archiving at any time. While the DVMS is continuously recording or archiving video, an unlimited number of authorized System Operators shall access video from a central archive server from client workstations connected to the data network (via a LAN or WAN connection). Up to 32 simultaneous System Operators shall access live or recorded video from a Digital Video Recorder. Using a centralized system administration tool, user defined profiles restrict each System Operators security access to specific video and to specific system operations, such as video monitoring, playback, adding, modifying, and deleting cameras. A user-friendly database query tool shall enable authorized System Operators to quickly locate video from any recorder and transparently play it back. The SYSTEM shall enable CUSTOMER to use off the shelf video enhancement software. These image enhancement kits allow the System Operator to enhance a single video capture frame. The single captured frames shall be a copy of the original recorded video. System Operators cannot alter the original recorded video in any way. The DVMS shall come with an image enhancement tool that shall be built into the digital video player (DVP). The design of the DVMS shall be flexible and allow for the following:

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 138

SECTION II

FUNCTIONAL REQUIREMENTS
a. Independent camera setup for, compression rate, brightness, contrast and other factor setups. This architecture shall allow System Administrators to optimize camera recording settings. Each camera shall have the ability to be set to operate with a different, compression rate, brightness, contrast and other factor setups. b. Total system solution to enable enterprise-wide, networked, multi-user access to all system resources via a wide range of options for connectivity with the customers existing LAN and WAN. c. Scalable, yet compact system design that offers modular expansion to protect CUSTOMER investment.

b) Network Interface The DVMS shall connect to an existing network. Various types of network architectures shall be supported including Ethernet 100BT, and Ethernet 1000BT. Various types of network protocols shall be supported including TCP/IP, IPX, and UDP. The network interface shall allow remote access of the recording system from various System Configuration and Alarm Monitoring client workstations located throughout the customer's facility. 1) Playback Over the LAN/WAN The DVMS shall be configured to playback stored video over the LAN/WAN for remote access of video clips. c) Seamless Integration with Total Security Knowledge Management Modules 1) Seamless Integration with Access Control and Alarm Monitoring The DVMS shall seamlessly integrate with the Access Control & Alarm Monitoring System. Any alarm/event in the SYSTEM shall have the ability to be associated with a digital video clip in real time. Each alarm/event in the SYSTEM shall store a pre-defined number of seconds of video before the event occurred and a pre-defined number of seconds of video after the event occurred. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the DVMS and the Access Control & Alarm Monitoring System. A separate database for the two systems is unacceptable. 2) Seamless Integration with Asset Management The DVMS shall seamlessly integrate with the Asset Management System. Any asset alarm/event in the SYSTEM shall have the ability to be associated with a digital video clip in real time. Each alarm/event in the SYSTEM shall store a predefined number of seconds of video before the event occurred and a pre-defined LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 139

SECTION II

FUNCTIONAL REQUIREMENTS
number of seconds of video after the event occurred. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the DVMS and the Asset Management System. A separate database for the two systems is unacceptable. 3) Seamless Integration with ID Credential Management The DVMS shall seamlessly integrate with ID Credential Management System. Any Credential Management or cardholder alarm/event in the SYSTEM shall have the ability to be associated with a digital video clip in real time. Each ID alarm/event in the SYSTEM shall store a pre-defined number of seconds of video before the event occurred and a pre-defined number of seconds of video after the event occurred. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the DVMS and the Credential Management System. A separate database for the two systems is unacceptable. 4) Seamless Integration with the Visitor Management The DVMS shall seamlessly integrate with the Visitor Management System. Any Visitor Management cardholder alarm/event in the SYSTEM shall have the ability to be associated with a digital video clip in real time. For each Visitor alarm/event in the SYSTEM shall store a pre-defined number of seconds of video before the event occurred and a pre-defined number of seconds of video after the event occurred. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the DVMS and the Visitor Management System. A separate database for the two systems is unacceptable.

d) Digital Video Recorders The Digital Video Recorder (LDVR) main storage medium shall be a digital hard drive. All video information shall be stored on the LDVR internal hard drive for immediate playback. The hard drive shall work in a FIFO (First In First Out) mode to allow new video clips to overwrite old clips. The DVMS shall have a clip-lock option to prevent overwriting of specific video clips regardless of their date and time. The LDVR shall also have an option to archive video to an off-line storage medium before the video is overwritten. The system shall support the use of local RAID 5 storage subsystems, which connect directly to the LDVR via RAID Controller Card. The system shall support the use of the following external storage solutions: SCSI, iSCSI, Fibre, IDE and SATA for this purpose. In all cases, initial system configuration shall take place via the respective third party software; however system function thereafter shall be seamless to the user. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 140

SECTION II

FUNCTIONAL REQUIREMENTS

The DVMS recording system shall capture, digitize, compress, and store video on a digital hard drive and archive onto digital tape or an array of hard disks. The DVMS shall support an unlimited number of Digital Video Recorders. Each Digital Video Recorder shall allow two video board configurations: 1) MPEG4: 8-Channel Video Board (up to 2 boards per chassis) which supports 8 channels at 3.75fps (NTSC) at 640 x 240 (640 x 480 interlaced) resolution; or 8 channels at 7.5fps (NTSC) at 320 x 240 resolution. 8 channels at 3.7fps (PAL) at 640 x 240 (640 x 480 interlaced) resolution; or 8 channels at 6.2fps (PAL) at 320 x 240 resolution. 2) MPEG4: 4-Channel 30fps Video Board (up to 4 boards per chassis) which allows simultaneous recording of up to 16 high motion cameras. Each camera may record at 30fps, 15fps, 7.5fps, 2fps, or 1fps (NTSC) and 25fps, 12.5fps, 6.2fps, 2fps, or 1fps (PAL). These can be at 320x240, 640x480 or 720x480. The Digital Video Recorder shall communicate with the SYSTEM Alarm Monitoring and System Administration client workstations over the CUSTOMER network or a private security network. The DVMS shall support all types of networks such as Ethernet over TCP/IP, IPX, and UDP protocols. The Digital Video Recorder shall record camera signals from fixed color and fixed black & white cameras, dome, infrared cameras, x-ray cameras, and low light cameras. Digital Video Recorder cameras shall provide industry-standard 1 Volt peak-to-peak signal strength to be used by the video recorder and provide 0.3 vertical synch Each LDVR shall have the ability to be given a realistic name of up to 32 alphanumeric characters and shall have the ability to be marked on-line or off-line. Each LDVR shall be given a workstation name as well as an IP address of where the LDVR is connected to the network. Each LDVR shall also have a World Time Zone setting to allow LDVR to reside in different areas of the world. The DVSM shall be able to accommodate up to 13 Dry Contacts (Inputs) from industry standard alarm inputs. System Administrators shall be able to configure the 13 alarm inputs individually through the System Administration Application. Inputs received through the dry contact ports shall be treated in the same manner as inputs received by traditional SYSTEM Access Control Field Hardware. Should the LDVR go offline, a specific alarm will be sent to Alarm Monitoring. Furthermore, a red X will display over the LDVR icon in the system status tree. Once the LDVR is brought back online, the red X shall no longer display. The DVMS shall be available in two chassis configurations:

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 141

SECTION II

FUNCTIONAL REQUIREMENTS

a. LDVR/UVS Standard Chassis (DVC-ST) includes 4U, 19-inch rack mount chassis with Intel P4 3.0GHz single core CPU, 1GB 533MHz RAM, Windows XP Professional operating system, Dual 10/100/1000 Ethernet ports, one 80GB OS only hard drive (UP TO 3 data hard drives KIT OPTIONS AVAILABLE), DVD/CD ROM, mouse and rack mount rail kit. LDVR/UVS Extended Storage Chassis (DVC-EX1) includes 3U, 19-inch rack mount chassis with Intel P4 3.0GHz single core CPU, 1GB 533MHz RAM, Windows XP Professional operating system, Dual 10/100/1000 Ethernet ports, one 80GB OS only hard drive, (UP TO 8 data hard drives KIT OPTIONS AVAILABLE), DVD/CD ROM, mouse and rack mount rail kit. e) Integrated Support for Embedded Standalone Digital Video Recorders The SYSTEM shall provide integrated support for embedded standalone digital video recorders (ESDVR). The system administrator shall be able to perform basic configuration of the ESDVR in the SYSTEM's system administration application. The system administrator shall be able to apply advanced configuration from the recorder web page. The SYSTEM shall support H.264 though the ESDVR. The ESDVR channels shall be supported in the SYSTEM's Remote Monitoring application. The ESDVR channels shall fully operate in the SYSTEM's VideoViewer browser-based client. The SYSTEM's IntelligentVideo Servers shall able to be configured for ESDVR. Import from the ESDVR shall be supported so that the configuration of the recorder can be imported and persisted in the SYSTEM's database. Inputs/Outputs shall be able to be configured and viewed through the SYSTEM. Changing of the password for the ESDVR through the SYSTEM shall be supported. f) Digital Video Cameras 1) Individual Camera Input Setup Each digital video camera (camera) shall be independently configured to record digital video. With the MPEG4 8-Channel video board, up to 16 cameras shall be connected to a single Digital Video Recorder (LDVR). Recording rates shall be variable, but no less than .9 frames per second and up to 7.5 frames per second (NTSC) and no less than .7 frames per second or 6.2 frames per second (PAL) at CIF (352 x 240 NTSC or 352 x 288 PAL) resolution. Alternatively, the MPEG4 8-Channel video board, recording rates shall be variable, but no less than .9 frames per second and up to 3.75 frames per second (NTSC) and no less than .7 frames per second and up to 3.1 frames per second (PAL) at 640 x 240 resolution (Viewed at VGA (640x 480)). With the MPEG4 4-Channel video board, up to 16 cameras shall be connected to a single LDVR. Recording rates shall be variable, but no less than .9 frames per second and up to 30 frames per second (NTSC) (no less than .7 frames per second or 25 frames per second (PAL)) at CIF (352 x 240 NTSC or 352 x 288 PAL) resolution. Alternatively, the MPEG4 4-Channel video board, recording rates shall be variable, but no less than .9 frames per second and up to 30 frames per second (NTSC) (no less than .7 frames per second and up to LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 142

SECTION II

FUNCTIONAL REQUIREMENTS
25 frames per second (PAL)) at 4CIF (704 x 480 NTSC or 704 x 576 PAL) and D1 (720 x 480 NTSC or 720 x 576 PAL) resolutions. Each camera shall have the ability to be given a realistic name of up to 32 alphanumeric characters and shall allow for the setup and adjustment of brightness, contrast, archiving, motion detection, Pan/Tilt/Zoom, on a per camera basis. The DVMS shall recognize the LDVR and channel that the camera is connected. System Administrators shall define whether each camera allows Pan/Tilt/Zoom commands to be accomplished from the Digital Video Player. Each camera shall have recording settings to customize the recording properties of the camera including: 1) Compression the compression of video input (MPEG4). 2) Pre-Roll - the number of seconds back of video that the DVMS will store from the time that a linked event is generated. 3) Post-Roll - the number of seconds forward of video that the DVMS will store after a linked event is generated. The DVMS shall support camera configuration setup wizard to guide System Administrators through the configuration of cameras. The setup wizard shall guide System Administrators step by step by asking a series of questions that, when answered, will allow the DVMS to configure cameras automatically. 2) Generate Motion Detection Alarms Each camera shall have the ability to record video to the DVMS based on motion detection of the camera. The times that motion detection recording occurs shall be user definable on a time zone basis. A sensitivity bar shall be available to adjust the sensitivity for motion in the cameras. Each camera shall have the ability to have a separate time zone and motion detection settings if desired. Areas of the video picture shall be configured to ignore motion. Motion in these areas shall not generate alarms. 3) Time-Lapse Recording The DVMS shall allow the ability to configure time-lapse recording on a camera by camera basis. System Administrators shall have the ability to configure cameras to record one frame of video every (x) seconds (1-30 seconds) when there is no motion in the viewing area. Once motion is detected, the DVMS shall automatically increase recording rate to a pre-defined frame rate.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 143

SECTION II
4) Individual LDVR Output Setup

FUNCTIONAL REQUIREMENTS

LDVR outputs shall be used for playback and monitoring of video independently. Each output shall have the capability of playback at the same frame rate as recorded. In addition, date, time, camera name, and playback mode shall be set to each output channel independently. 5) Continuous Recording Mode The DVMS shall allow continuous recording of all cameras. Recording rates shall be variable based on video board type, the number of cameras, and resolution. All cameras shall have the capability to be recorded and archived simultaneously at the recording rate of the cameras. The SYSTEM shall allow monitoring and playback without interfering with the recording operation. In this mode, an alarm trigger shall mark a segment as an event for later query and search capability. g) Device Linkages The DVMS shall seamlessly integrate with the Access Control & Alarm Monitoring System. Each access control field hardware device that is configured in the SYSTEM shall be configured to be linked with a camera from the DVMS. A camera shall have the ability to be linked with multiple access control hardware devices and an access control hardware device shall have the ability to be linked with multiple cameras. An unlimited number of access control hardware/device links shall be configurable. A camera viewing priority shall be given to each access control hardware device link. In the event that multiple cameras linked to a single access control hardware device generate an alarm, the camera with the higher priority will show in the Alarm Monitoring Video Window first, followed by cameras with lower priority. Each alarm/event condition shall have the ability to mark the start of a video event or the end of a video event in real time. For example, when a door forced open is activated, the DVMS can mark the start of the video event. When the door forced open restored alarm occurs, the DVMS can mark the end of the video event. For alarms that mark the start of the video event, a default Video Event Timeout shall be available that will end the video event in the case that a restoral alarm does not occur or if there is no restoral alarm for the event. System Administrators shall have the option for each alarm/event to automatically launch the Digital Video Player at the Alarm Monitoring client workstation when an alarm or event is generated. If an alarm is configured to automatically launch the Video Player, the system operator shall have the option to configure it to launch recorded video in addition to live video. The operator shall have the option to configure the recorded video to play the device playback pre-roll video or the image at the time of the event.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 144

SECTION II

FUNCTIONAL REQUIREMENTS

The DVMS shall support device linkage configuration setup wizard to guide System Administrators through the configuration of the device-camera links. The setup wizard shall guide System Administrators step by step by asking a series of questions that, when answered, will allow the DVMS to configure device-camera links automatically. h) Video Archiving The DVMS shall have the capability to archive stored video from the Digital Video Recorder to another workstation or off-line storage mechanism. Each LDVR shall have the capability to setup its own unique archiving properties. Each LDVR shall communicate through an Archive Server that shall run as a service on a Windows 2008/2003 Server (if archiving to a tape library). An Archive Server shall have the ability to communicate with multiple DVRs if desired. The Archive Server shall work in cooperation with the Storage Server, which shall be either any disk volume on the network or a volume on a Windows 2008/2003 Server PC configured for Remote Storage. Remote storage is a subsystem on Windows 2008/2003 Server that shall automatically maintain a certain percentage of free space on the disk volume by transferring data from disk to tape media (and automatically recalling the files back to disk when they are needed). The Storage Server based on Windows 2008/2003 Remote Storage shall also run an additional service supplied by MANUFACTURER to facilitate the recalling of stored files by the Digital Video Players at the Alarm Monitoring client workstations. Event archiving can be used when a LDVR accumulates enough locked video events to cross a configured threshold, a request shall be sent to the Archive Server to archive video events from that LDVR. In response to the request, the Archive Server shall begin transferring video events from the LDVR to the storage volume specified as events storage for that LDVR. Video events shall be transferred until the storage used by events on the LDVR is below the configured threshold. The threshold shall be configurable to the percentage of hard disk space that is available on the LDVR. The System Administrator shall have the ability to configure the DVMS to free up a user-defined percentage of hard disk space once the aforementioned threshold is reached. Event based archiving is available for all video board types. Each LDVR shall have the ability to be configured for purging events instead of archiving. In that case, the Archive Server shall simply purge events by removing the locked status from the oldest locked events, thus allowing them to be overwritten, rather than transfer them to the storage volume. Event locking and purging is available for all video board types. To provide a degree of fault tolerance, the Archive Server shall have a facility to store failed archiving operations to be retried later. This functionality shall be automatic and shall not require any configuration.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 145

SECTION II

FUNCTIONAL REQUIREMENTS

Once video is archived, a System Operator shall be able to seamlessly retrieve video clips from the archived location using the Digital Video Player at any Alarm Monitoring client workstation. i) Audio The DVMS shall support G.711 audio integration. Up to sixteen channels of audio are available per LDVR using MPEG4 8-Channel or MPEG4 4-Channel Video boards in conjunction with a 16 Channel Audio add-in board, allowing up to sixteen audio channels to be associated with up to sixteen video channels for synchronized playback and live viewing of video and audio data. There is a maximum of one audio channel per video channel. The audio functionality shall be backwards compatible on select LDVR models, requiring only the addition of the 16 Channel Audio add-in board and a firmware upgrade to enable this new functionality on select existing systems. The USER shall be able to control the volume as well as have the ability to mute the audio recording during playback utilizing standard windows sound card controls. Additionally, both the MPEG4 8 channel and MPEG4 4 channel boards shall support single channel audio. The USER shall be able to connect a microphone using either the Microphone or Line audio port on the back panel of the LDVR chassis. The user shall be able to configure the audio channel through the System Administration module; selecting which video camera the microphone shall be associated with. j) Video Viewer Application The DVMS shall support a stand-alone digital video viewing application that allows live and recorded video to be viewed from a streamlined viewing interface. The digital video viewer supports the advanced video functionality of an alarm monitoring workstation including matrix viewing, live, recorded, or both live and recorded video simultaneously. The new and simplified user interface shall be installed on any PC workstation meeting minimum requirements. This application will also be utilized by a non-SYSTEM user to view an exported video clip. Video clips may be exported and burned to disc as well as emailed or saved to a directory on a network. The video viewer application will display exported video clips with both time and date stamp for the video. This application shall be able to be used to view live or recorded video without utilizing one of the SYSTEM client licenses. The user shall be able to review up to ten minutes of live video from video cache memory without the need to switch from live to recorded video. Users shall have the option to pause, resume, slow or accelerate cache memory video.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 146

SECTION II

FUNCTIONAL REQUIREMENTS

The video viewer application shall be able to display motion detection alarms as well as communication lost alarms and traces shall be able to be based on those alarms for reporting purposes. All of the cameras in the system shall be displayed in the System Status Tree via the video viewer application. The video viewer application shall support the advanced search capabilities available via the Video Search functionality. The System Operator shall be able to select various Video Quality Enhancement (VQE) algorithms that will improve the viewing quality of specified video channels on the client viewing station. The System Operator shall be able to select the "Fog Removal" algorithm. The System Operator shall have improved video as fog in the foreground will be diminished. The System Operator shall be able to select the De-Interlacing algorithm and the artifacts affects of compression and interlacing will be diminished. The System Operator shall be able to select the sharpen algorithm and a camera view which is blurred shall be diminished. The impact on the above three VQE algorithms shall only impact the workstation in which the changes were made and shall not impact recorded video or other workstation viewing of the video. k) Video Viewing Layouts The DVMS shall provide a user the ability to save the list of cameras currently being played along with the currently selected template, if one is selected, under a user given layout name. The DVMS shall also include pre-configured layouts. The DVMS shall allow for user created layouts, single view, matrix view, and other preconfigured layouts to loaded as desired by the System User. l) Browser-Based Video Viewer The SYSTEM shall provide a browser-based video viewer option. The SYSTEM shall automatically download and install any required components directly onto the browser. The browser-based video viewer shall have a fully customizable layout. This browserbased video viewer shall provide the following functionality: 1) Display live and recorded video from any LDVR or LNVR 2) Digital zooming/panning 3) PTZ camera control a) Relative Mode (Drag or double-click-to-center)

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 147

SECTION II

FUNCTIONAL REQUIREMENTS
b) Mixed Mode (continuous or click-to-center) c) Continuous Mode (click and hold to move) d) PTZ access management to prevent multiple users access during viewing 4) Ability to access video from multiple recorders 5) Multiple video window (cell) selection of which one window may be for live video viewing and one window for recorded video viewing 6) Time date selection of recorded video by viewing cell 7) Return to start of a displayed video clip with a single mouse click 8) Transfer recorded video clips to DVD or CD 9) Support for specific PTZ video controllers via USB direct connect or RS485:

The browser-based video viewer shall use an N-tiered architecture. Browser-based video viewer requires the use of Internet Explorer 6.0 or 7.0 and 1024x768 resolution. 1) Browser-Based PTZ Locking When a System User selects a cell that contains a PTZ camera the SYSTEM shall attempt to lock it to eliminate another System User with lower priority from taking control of the camera. To allow a System User with lower priority to use the PTZ camera the initial System User must unlock the PTZ camera. m) Alarm Monitoring The DVMS shall seamlessly integrate with the SYSTEM Alarm Monitoring Module. Upon generation of an alarm that is configured to mark video, the System Operator shall be able to recall the video segment associated with the alarm. Once launched, the System Operator shall have the ability to adjust the start and end time of the segment. The SYSTEM Alarm Monitoring Module shall be able to save the list of video windows, the video windows sizes, the video windows locations, and the all the selected camera options under a System Operators profile. The next time the System Operator runs Alarm Monitoring the same list of video windows, the video windows sizes, the video windows locations, and the all the selected camera options shall be automatically launched.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 148

SECTION II
1) Real Time Monitoring

FUNCTIONAL REQUIREMENTS

The DVMS shall allow monitoring of real time video from any Alarm Monitoring client workstation. The System Operator shall be able to monitor any camera by using the System Hardware Status Tree and choosing the appropriate camera. Output of video for real time monitoring shall be transferred to an Alarm Monitoring client workstation over the LAN/WAN. In the DVMS, authorized System Operators shall be able to concurrently playback recorded video from any clip, even as that video clip is being recorded. The Play button shall enable System Operators to play back a single video segment at the maximum recording configuration. While viewing at 320x240, the DVMS has an integrated Matrix View that shall be able to play back up to 128 frames per second of video segments simultaneously at the maximum recording configuration on any Alarm Monitoring client workstation. While viewing at 640x240 or 640x480, the DVMS has an integrated Matrix View that shall be able to play back up to 72 frames per second of video segments simultaneously at the maximum recording configuration on any Alarm Monitoring client workstation. The SYSTEM shall monitor the firmware revision of the LDVR as well as hard drive space percentage being used for locked video. 2) Playback Control The DVMS Playback Control shall offer the following features for full System Operator control of video playback: b. Start and Stop Playback During operation of the viewer application, the authorized System Operator shall be able to start and stop playback. This operation shall not affect any other operation. c. Pause and Resume During playback of video, the System Operator shall be able to pause and resume current playback. This operation shall not affect any other operation. d. Fast Forward During playback of video, the System Operator shall be able to use the Fast Forward button to view the playback at faster than normal speed. This operation shall not affect any other operation. e. Skip Backward During playback of video, the System Operator shall be able to use the Skip Backward button to rewind the playback. This operation shall not affect any other operation. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 149

SECTION II
f. Frame Advance

FUNCTIONAL REQUIREMENTS

During playback of video, the System Operator shall be able to use the Frame Advance button to advance the video clip one frame at a time. This operation shall not interfere with any other operation. The System Operator shall also have the ability to switch between other cameras if the device that generated the event has more than one camera associated with it. The System Operator shall have the ability to adjust the start and end times of the video segment once the video segment is displayed. The System Operator shall also have the ability to adjust the playback speed of the video segment from slower than normal to real time to high speed playback. The System Operator shall have the option to switch to Live Mode from a camera at any time during the operation. The System Administrator shall also have the ability to load any video file from a backup device into the digital video player at any time. The digital video player shall be user configurable to show the date and time of the video clip frame, as well as the current mode of the player (play or live). The System Operator shall have the ability to display or not display the informational text. The digital video player shall also have the option to automatically launch upon a critical alarm occurring in the SYSTEM to show live video at the video camera linked to that hardware device. 3) Matrix View The DVMS / IPDVMS shall support an advanced matrix view of multiple live or recorded camera views. The number of Video Players that may opened and the total number of cameras available for viewing on any one video client workstation is limited only by the frame rate, resolution, and video standard of the cameras being viewed; the capacity of the WAN/LAN between the DVMS / IPDVMS and the video client workstation; and how powerful that video client workstation PC is. The Video Player shall allow operator sizing of the video windows in the matrix view. 4) Pan/Tilt/Zoom Control from Alarm Monitoring The DVMS shall support pan/tilt/zoom (PTZ) controls from the Alarm Monitoring Workstation. The PTZ control shall be supported in conjunction with matrix switchers such as those manufactured by Vicon, Pelco, and American Dynamics. Supported command settings shall be available for: 1. Pan Left 2. Pan Right 3. Tilt Up 4. Tilt Down

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 150

SECTION II
5. Zoom In 6. Zoom Out 7. Focus Near 8. Focus Far

FUNCTIONAL REQUIREMENTS
9. Iris Open 10. Iris Close 11. Go to Preset 12. Stop PTZ Movement

The DVMS shall support multiple matrix switchers. Cameras shall be connected to any matrix switcher, regardless of the DVMS in which they are connected. System Administrators shall be able to determine, on an individual basis, which cameras allow PTZ commands to be controlled from the Alarm Monitoring Workstation. For each camera that allows Pan/Tilt/Zoom command functionality, System Operators shall have the ability to control the above functionality through the Digital Video Player. The DVMS shall support the capability to control Pelco SpectraDome III analog PTZ cameras without the need of a matrix switch. 5) Video Camera Groups/Video Camera Tours The DVMS shall support camera grouping to allow for video camera tours to occur in the SYSTEM Alarm Monitoring Module. An unlimited number of camera groups shall be supported in the SYSTEM and each camera group shall support an unlimited number of cameras. Cameras within a camera group shall span multiple Digital Video Recorders. Cameras shall have the ability to be placed into multiple camera groups. Once grouped, the System Operator shall be able to start a video camera tour that shall rotate live video between each of the cameras defined in the video camera group at a user defined increment. The time increment (dwell time) between switching cameras shall be user definable in one second increments. 6) Still Image Capture During playback or monitoring of video, the System Operator shall use the Pause button followed by selecting Enhance Image from the Options Menu to create a still picture. This operation shall not affect any other operation and shall not alter the recorded video. 7) Still Image Save The captured image Export button shall allow System Operators to save single video frames to the client workstation hard drive in a standard file format. The System Operator shall be able to later e-mail, print, or transfer the file to any other media. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 151

SECTION II
8) Export Video Clip to File

FUNCTIONAL REQUIREMENTS

The System Operator shall have to ability to save and export recorded video to a file for the purpose of sharing and reviewing video clips. The start and end times for each video segment shall be determined by the System Operator. The exported video clip shall be viewable via a standard Windows media player. An optional time, date stamp, and user defined text has the option of being overlaid with a user defined transparency level. 9) Blind Camera Alarm The LDVR shall support the blind camera alarm. If for example, someone places something over the lens of the camera, the system will generate a blind camera alarm in Alarm Monitoring. 10) Video Image Processing The DVMS shall support video image processing of a single frame captured image through use of an image processing module. The image processing module shall show both the original captured image side by side next to the processed image. The following effects shall be available to System Operators to apply to an original captured image in any combination desired: 1) Intensity - Increases or decreases the overall intensity level of the light in the image. Adjusts the brighter areas by making them brighter or darker. 2) Contrast - Increases or decreases the range of gray levels contained in the image. It adjusts the distinction between the lightest and darkest tones in the image. 3) Saturation - Adjusts the purity of color (the number of colors used to create a particular color). 4) Gamma Correct - Enhances detail in the image by adjusting the middle tones without affecting the darkest and lightest areas. 5) HistoContrast - Adjusts the number of pixels per gray level to create a linear relationship between gray levels, used to bring out the detail in dark areas of the image. 6) Hue - Adjusts the main characteristic of a particular color that distinguishes it from other colors. 7) HistoEqualize - Redistributes shades of colors to adjust imbalances. It makes the darkest colors black and the lightest colors white and stretches the colors in-between. 8) Flip - Flips the image horizontally (the image will appear upside down).

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 152

SECTION II

FUNCTIONAL REQUIREMENTS
9) Reverse - Flips the image vertically, creating a mirror image of the original. 10) Rotate - Rotates the image 0-360 degrees. 11) Shear - Applies the look of three-dimensionality to the image, while maintaining the original size and shape. 12) Add Noise - Creates a granular effect that adds texture to a flat or overly blended picture. 13) Average - Converts each pixel in the image to the average of itself and the pixels to the right and bottom, resulting in a blurring of the image. 14) Sharpen - Enhances the edges and brings out the detail. 15) Halftone - Converts the image to a black and white (1 bit/pixel) image in which different shades of gray (luminance) are represented by different patterns of black and white pixels. 16) Median - Reduces the amount of graininess (noise) in an image. 17) Emboss - Converts the image to a raised relief style with its light source directed from the top left. 18) Gray Scale - Represents the image using up to 256 shades of gray. 19) Invert - Inverts the colors in the image as on a photographic negative. 20) Mosaic - Converts the image to a grid of square blocks of color. 21) Posterize - Reduces the color resolution, which is the number of shades of color that shall be displayed simultaneously. The DVMS shall allow for the System Operator to save any combination of effects as a profile to be used on other still images for image processing. Profiles shall have the ability to be added or deleted from the SYSTEM at any time. 11) Resizable Video Window During playback or monitoring of video, the System Operator shall be able to enlarge the size of the video screen to twice the recorded resolution to have video display larger on the monitor screen. This operation shall not affect any other operation. 12) Video Validation The LDVR shall detect video loss from any or all cameras. If a camera stops transmitting video or the BNC cable from a camera to the LDVR is disconnected or malfunctions, the DVMS supervision shall detect the video loss and will alert the System Operator via the alarm monitoring client workstation window, audible alarm, visual alarm, or pager.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 153

SECTION II
n) Intelligent Motion Video Searching

FUNCTIONAL REQUIREMENTS

The DVMS shall support advanced automated motion video searching against prerecorded video. The automated motion video search shall analyze frames in a video segment to detect motion activity from image to image. It shall display thumbnail images of the frames with activity, complete with a histogram depicting the relative amount of activity within each frame. System Operators shall be able to perform this search by selecting a specific camera, a specific area of the cameras field of view via the user generated polygon feature, and a specific time period in which the suspected activity took place. The DVMS shall then locate all motion events associated with that camera and time period and display them in trace format or by thumbnail format. The System Operator can then select the event or thumbnail and the system shall automatically begin playing the motion event. The System Operator shall then be able to view each of the individual events through the camera video window. o) Video Export The DVMS shall be able to export user selected video clips to the industry standard .ASF format for viewing in industry standard video viewers such as Microsoft Windows Media Player format. The System Operator shall be able to add text to the clip as well as be able to modify the color, size and position of the font. The System Operator will be able to position the time/date stamp as well as modify the color, size, and transparency of the font. The video clip may be sent via email, burned to disc or stored on a directory. The recipient will have the ability to view video without the need for having the SYSTEM Client software installed on their PC machine. p) Video Authentication The DVMS shall provide imbedded authentication of video. The video shall be watermarked with an authentication key/signature during the export of the video. The video player shall have the ability to verify the videos authenticity during playback. The authentication shall provide the recorder name, camera name, video time, and user information. The authentication shall be password protected. q) On-line Context Sensitive Help The DVMS shall provide on-line context sensitive help files to guide the System Administrators and System Operators in the configuration and operation of the DVMS. The help menu shall be available from any window in the DVMS by pressing the F1 function key or clicking on the help icon in the toolbar. Help windows shall be context sensitive so System Operators can move from form to form without leaving the help window. Standard windows help commands for Contents, Search, Back, and Print shall also be available. The DVMS shall also come with complete on-line documentation on the product DVD.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 154

SECTION II 7. Intelligent Video

a) Overview

FUNCTIONAL REQUIREMENTS

The Intelligent Video Server (IVS) shall be available as a solution that is seamlessly integrated with other Total Security Knowledge Management Solution Modules, including Access Control & Alarm Monitoring, Asset Management, ID Credential Management, and Visitor Management. The IVS shall be capable of automatically upgrading firmware by using the SYSTEM scheduling mechanism. All functionality described from this point forward shall reflect functionality of the seamlessly integrated system. Intelligent video shall be an alert-based system. The System Administrator shall select one or more of a pre-defined list of Algorithms and configure these events. The SYSTEM shall send alerts whenever a selected event occurs. List of Events a. b. c. d. e. f. g. h. i. j. k. l. m. n. o. b) Events 1) Smart Video Motion Detection The SYSTEM shall support a smart video motion detection event that shall act just like traditional video motion detection but shall have the added option of ignoring camera vibrations and motion masks. 2) Invalid Camera The SYSTEM shall support an invalid camera event that shall detect whenever a camera is covered, moved, or is altered to be out-of-focus. 3) Object Left Behind The SYSTEM shall support an object left behind even that shall detect whenever an object is static in a foreground scene for a predefined period of time. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 155 Smart VMD Invalid Camera Object Left Behind Object Removed Object Detection Congestion Directional Motion Object Crosses a Region Object Stops Object Starts to Move Object Moves too Fast Object Lurking Loitering Facial Detection People Counting

SECTION II
4) Object Removed

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support an object removed event that shall detect whenever an object that was part of the background is moved from its place, such as when a vehicle leaves an area. 5) Object Detection The SYSTEM shall support an object detection even that shall detect objects in the view of the camera. The object can be defined by object properties and object color. Configuration parameters shall be available for region of interest, size, eccentricity, orientation, and color (hue, grayness, whiteness, and blackness). The object detection event shall be able to detect a group of people. 6) Congestion The SYSTEM shall support a congestion event that shall detect overcrowding in a selected area such as in a lobby or hallway. 7) Directional Motion The SYSTEM shall support a directional motion event that shall detect motion of objects in a specific direction, such as a vehicle moving in the wrong direction. 8) Object Crosses a Region The SYSTEM shall support an object crosses a region event that shall detect when an object crosses a virtual line, typically used to monitor restricted areas, traffic, or perimeter fences. 9) Object Stops The SYSTEM shall support an object stops event that shall detect when an object enters the view and then stops, such as a vehicle entering an area in front of a building and stopping. 10) Object Starts to Move The SYSTEM shall support an object starts to move event that shall detect when an object in view of the camera begins to move from a stopped state. 11) Object Moves too Fast The SYSTEM shall support an object moves too fast shall detect an object that moves faster than a user-definable threshold. The maximum allowed speed of the object shall be defined in terms of a time interval to cross a defined distance. The distance shall be defined by two lines marked by the System User. The alarm shall be generated if the object moves from one line to the other in less than the pre-defined time interval.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 156

SECTION II
12) Object Lurking

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support an object lurking event that shall detect objects that were moving and then slowed down or stopped for at least 7 seconds. The object can be human, vehicle, or other. The object must move for a length of at least 20 pixels before lurking begins. 13) Loitering The SYSTEM shall support a loitering event that shall detect when a person loiters in an area, such as in a lobby or hallway, for more than a pre-determined amount of time. Parameters shall be available for duration and object size. 14) Facial Detection The SYSTEM shall support a facial detection event that shall detect if a face is present within the view of the camera, such as monitoring an entry point into a restricted area. 15) People Counting The SYSTEM shall support a people counting event that shall count the number of people entering and exiting an area. c) Intelligent Video Embedded Analytics The SYSTEM shall support the use of Video Analytics that are embedded on an IP Camera. The SYSTEM shall support the following analytics available through an IP Camera: Invalid Camera, Loitering, Object Detection, and Smart Video Motion Detection. Intelligent Video embedded analytics is a digital video analysis system with the ability to recognize, analyze, and classify information. Embedded analytics process the video directly on the camera rather than by the LNVR or Intelligent Video Server. Embedded analytics is currently supported for the following events: Invalid Camera, Loitering, Object Detection, and Smart Video Motion Detection. d) Additional Mechanisms i. Automatic Detection of PTZ Out of Home Position The SYSTEM shall automatically detect when a PTZ camera is out of its home position and disable the intelligent video processing until the camera returns to home position. ii. Automatic Detection of Poor Visibility The SYSTEM shall detect when visibility degrades below a pre-defined threshold and display a warning in the Alarm Monitoring application. e) Intelligent Video Application Server The SYSTEM shall support the use of an Intelligent Video Application Server. The application server shall work in conjunction with intelligent video events to provide a

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 157

SECTION II

FUNCTIONAL REQUIREMENTS

more dynamic feature set. The application server shall be a fully integrated component of the SYSTEM. The following applications shall be supported by the application server 1) Facility Utilization The SYSTEM shall provide a facility utilization feature. This feature shall work in conjunction with the intelligent video event, people counting, described above. This feature shall be able to process people counting information for groups of doors. The Facility Utilization feature shall be able to provide information on traffic flow as well as occupancy information. This information shall also be capable of being provided in a report format for printing. f) Seamless Integration with Total Security Knowledge Management Modules 1) Alarm Monitoring System The Intelligent Video Server shall seamlessly integrate with the Access Control & Alarm Monitoring System. Any event in the intelligent video server shall have the ability to be associated with an SYSTEM event. Each event in the intelligent video server shall be able to activate a SYSTEM event. The same database MUST store information from both the Intelligent Video Server and the Access Control & Alarm Monitoring System. A separate database for the two systems is unacceptable. 2) Seamless Integration with Asset Management The Intelligent Video Server shall seamlessly integrate with the Asset Management System. Any asset alarm/event in the SYSTEM shall have the ability to be associated with an intelligent video event. Each alarm/event in the SYSTEM shall be associated with a video clip. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the Intelligent Video Server and the Asset Management System. A separate database for the two systems is unacceptable. 3) Seamless Integration with ID Credential Management The Intelligent Video Server shall seamlessly integrate with the ID Credential Management. Any asset alarm/event in the SYSTEM shall have the ability to be associated with an intelligent video event. Each alarm/event in the SYSTEM shall be associated with a video clip. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the Intelligent Video Server and the ID Credential Management System. A separate database for the two systems is unacceptable.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 158

SECTION II

FUNCTIONAL REQUIREMENTS
4) Seamless Integration with the Visitor Management The Intelligent Video Server shall seamlessly integrate with the Visitor Management System. Any asset alarm/event in the SYSTEM shall have the ability to be associated with an intelligent video event. Each alarm/event in the SYSTEM shall be associated with a video clip. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the Intelligent Video Server and the Visitor Management System. A separate database for the two systems is unacceptable. 5) Seamless Integration with the Digital Video Management System The Intelligent Video Server shall seamlessly integrate with the Digital Video Management System. Any asset alarm/event in the SYSTEM shall have the ability to be associated with an intelligent video event. Each alarm/event in the SYSTEM shall be associated with a video clip. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the Digital Video Management System and the Intelligent Video Server. A separate database for the two systems is unacceptable

g) Intelligent Video Overlay The IVS shall provide the ability to store the graphical output for an event for use with intelligent video alarms. This feature shall allow the graphical output of an event to be stored as a file that later can be viewed as an overlay with the video associated with the alarm. h) Intelligent Video Resolution The IVS shall be able to support CIF (352 x 240 NTSC or 352 x 288 PAL), 4CIF (704 x 480 NTSC or 704 x 576 PAL) and D1 (720 x 480 NTSC or 720 x 576 PAL) video resolutions during video processing. i) Intelligent Video Imaging Support The IVS shall be able to support video infra-red (IR) imaging. j) Audio Analysis The SYSTEM shall be able to perform analysis on audio associated with recorded video. The SYSTEM shall be able to search video for impact sounds. The search shall produce a still frame thumbnail video at the time of the start of the detected audio event. The audio analysis shall be able to be performed on video files, video on a recorder as well as video on an archive server.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 159

SECTION II
k) On-line Context Sensitive Help

FUNCTIONAL REQUIREMENTS

The IVS shall provide on-line context sensitive help files to guide the System Administrators and System Operators in the configuration and operation of the IVS. The help menu shall be available from any window in the IVS by pressing the F1 function key or clicking on the help icon in the toolbar. Help windows shall be context sensitive so System Operators can move from form to form without leaving the help window. Standard windows help commands for Contents, Search, Back, and Print shall also be available. The IVS shall also come with complete on-line documentation on the product disc.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 160

SECTION II 8. Intelligent Video Solutions

a) Overview

FUNCTIONAL REQUIREMENTS

Intelligent Video Solutions Packages shall be integrated into DVMS. These solutions shall be preconfigured event and channel configuration settings for the most common intelligent video scenarios to which the System User, with minimal calibration, is able to apply to a camera. IV solutions shall be seamlessly integrated into DVMS and shall operate in conjunction with Alarm Monitoring

b) Solutions 1) Intrusion Detection The SYSTEM shall support an intrusion detection solution allowing for the detection of, and differentiation between, humans, vehicles, and small animals. The intrusion detection solution shall be capable of being used in both interior and exterior situations. The intrusion detection solution shall contain advanced mechanics that distinguish between moving trees or other inanimate objects so as to avoid false alarms. 2) Standing Vehicle The SYSTEM shall support a standing vehicle solution that shall detect vehicles that are left within a user defined area for a user defined amount of time. 3) Forbidden Direction and Path of Motion The SYSTEM shall support a forbidden direction and path of motion solution that shall allow for the user to define a specific region along with a specific direction. If an object moves in the specified region and in the specific direction it shall be detected by the SYSTEM. 4) Crowd Control The SYSTEM shall support a crowd control solution that shall detect when a line of people exceed a pre-defined length in a designed area of interest. 5) Loitering The SYSTEM shall support a loitering solution that shall detect a person remaining in designated area for a pre-defined amount of time. 6) Facility Utilization The SYSTEM shall support a facility utilization solution that shall allow for counting of people entering and exiting a user defined area through a user defined

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 161

SECTION II

FUNCTIONAL REQUIREMENTS
group of access points. The SYSTEM shall be able to utilize this information of flow of people to trigger SYSTEM outputs. 7) Smart Camera The SYSTEM shall support a smart camera solution that shall allow for a camera to detect motion. The smart camera solution shall ignore changes in lighting, precipitation, and wind or other camera vibration when determining if an object is moving in the cameras view. This solution shall provide for Video Stabilization False Object detection Correction for three-dimensional object size Detection of PTZ camera out of home position

c) Intelligent Video Solution Mode The SYSTEM shall allow for the implementation of intelligent video solutions on selected cameras in addition to manually adding and configuring intelligent video events.

9. Intrusion Detection
a) Overview The Intrusion Detection Management System (IDMS) shall provide advanced, seamless integration with Intrusion Detection Panels from Bosch (D9412 and D7412), Detection Systems (7400xi and 7400xi 4+), Honeywell (Galaxy 8, 18, 60, 128, 500, 504, 512), and Guardall (xL, PX, QX, and RX). The IDMS shall allow CUSTOMER to monitor intrusion detection alarms inside the SYSTEM Alarm Monitoring module, in addition to giving CUSTOMER command and control of supported intrusion detection devices (such as arming and disarming an area). Once alarms are brought into SYSTEM, they shall be linked to digital video, global I/O activity shall be triggered, and they shall be stored in the SYSTEM audit trail. In addition, System Operators shall monitor the status of intrusion detection devices from the SYSTEM Alarm Monitoring workstation. The SYSTEM shall not be the mechanism for initial configuration and setup of Intrusion Detection Devices and basic intrusion detection functionality. All IDMS configuration listed below shall be for used for integration functionality within the SYSTEM. b) System Administration Integration 1) Intrusion Detection Panels The IDMS shall allow for the configuration of an Intrusion Detection Panel. Each Intrusion Detection Panel shall be given a user defined name for up to 32 LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 162

SECTION II

FUNCTIONAL REQUIREMENTS
characters. A workstation name shall be assigned to the intrusion detection panel. System Administrators shall have the ability to mark Intrusion Detection Panels as on-line or off-line depending on the state of the panels. The following intrusion detection panels shall be supported:
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.

Bosch D9412 Bosch D7412 Bosch D9412G Bosch D7412G Bosch D9412GV2 Bosch D7412GV2 Detection Systems DS7400Xi Detection Systems DS7400Xi Version 4+ Honeywell Galaxy 8 Honeywell Galaxy 18 Honeywell Galaxy 60 Honeywell Galaxy 128 Honeywell Galaxy 500 Honeywell Galaxy 504 Honeywell Galaxy 512 Guardall xL Guardall PX Guardall QX Guardall RX

The intrusion detection panels communication shall be either Direct RS-232 or LAN connection. An agency code and pass code shall be configured to allow the ability to Login to the panel (Detection Systems only).

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 163

SECTION II

FUNCTIONAL REQUIREMENTS
When a panel is added, onboard devices (zones, relays) shall be defined and added to the SYSTEM database. 2) Intrusion Detection Zones The IDMS shall allow for the configuration of Intrusion Detection Zones. Each Intrusion Detection Zone shall be given a user defined name for up to 64 characters. System Administrators shall have the ability to mark intrusion detection zones as enabled or disabled. System Administrators shall have the ability to mark intrusion detection zones as output zones (Detection Systems Only). The following number of Intrusion Detection zones shall be able to be configured for each panel:
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

D9412 shall support 246 zones D7412 shall support 75 zones 7400Xi shall support 128 zones 7400Xi 4+ shall support 248 zones Honeywell Galaxy 8 shall support 8 zones Honeywell Galaxy 18 shall support 18 zones Honeywell Galaxy 60 shall support 60 zones Honeywell Galaxy 128 shall support 128 zones Honeywell Galaxy 500 shall support 500 zones Honeywell Galaxy 504 shall support 504 zones Honeywell Galaxy 512 shall support 512 zones Guardall xL shall support up to 256 zones, depending on model Guardall PX shall support up to512 zones, depending on model Guardall QX shall support up to 32 zones, depending on model Guardall RX shall support up to 32 zones, depending on model

13.

14.

15.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 164

SECTION II
3) Intrusion Detection Areas

FUNCTIONAL REQUIREMENTS

The IDMS shall allow for the configuration of Intrusion Detection Areas. Each Intrusion Detection Area shall be given a user defined name for up to 64 characters. System Administrators shall have the ability to mark intrusion detection areas as enabled or disabled. 4) Intrusion Detection Panel Users The IDMS shall allow for the configuration of Intrusion Detection Panel Users. A Panel User shall be able to be linked to a SYSTEM cardholder record. 5) Intrusion Detection Onboard Relays The IDMS shall allow for the configuration of Intrusion Detection Onboard Relays. Each Intrusion Detection Onboard Relay shall be given a user defined name for up to 64 characters. System Administrators shall have the ability to mark intrusion detection Onboard Relays as enabled or disabled. 6) Intrusion Detection Off-board Relays The IDMS shall allow for the configuration of Intrusion Detection Off board Relays. Each Intrusion Detection Off board Relay shall be given a user defined name for up to 64 characters. System Administrators shall have the ability to mark intrusion detection Off board Relays as enabled or disabled. 7) Intrusion Detection Doors The IDMS shall allow for the configuration of Intrusion Detection Doors. Doors shall be able to be configured for each panel. Each Intrusion Detection door shall be given a user defined name for up to 64 characters. System Administrators shall have the ability to mark intrusion detection doors as enabled or disabled. c) Alarm Monitoring Integration The SYSTEM shall allow for annunciation of intrusion detection alarms in the Main Alarm Monitoring Window. Intrusion Detection alarms reporting into the Main Alarm Monitoring Window shall report just like any other access control alarm and shall have the same annunciation and display properties as access control alarms (See Section II, Number 2, Bullets b and c). 1) Alarm View Alarms from the Intrusion Detection panel shall be displayed in the Main Alarm Monitoring Window. In the Alarm View, the following columns shall be utilized:

1. Alarm Description 2. Time/Date 3. Controller - shall display the name of the Controller
LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 165

SECTION II

FUNCTIONAL REQUIREMENTS 4. Device - shall display the name of the Device (zones, onboard relay,
off board relay, door)

5. Card shall display the name of the linked SYSTEM cardholder 6. Alarm Priority 7. Text - shall indicate whether there is additional text associated with the
alarm

8. Intrusion Area - shall indicate the name of the area associated with the
alarm. 2) Alarm Details The SYSTEM shall support an Alarm Details description that shall show the Alarm Description, Time/date, Controller, Device, and Area associated with the alarm. The information shall also display the linked SYSTEM user. 3) System Hardware Status Tree Intrusion Detection devices and areas (controllers, zones, onboard relays, off board relays, doors) and areas shall be displayed in the System Hardware Status Tree. 4) Intrusion Detection Tracing The IDMS shall support tracing of intrusion detection devices and areas (see Section II letter l for details). 5) Real Time Status Indicators and Information The SYSTEM shall be able to report status information for the Intrusion Detection Devices. The following Status Information for Intrusion Detection Panels shall be able to be displayed (R in parenthesis (R) means Bosch only, DS in parenthesis (DS) means Detection Systems only, G in parenthesis (G) means Galaxy only):
1. 2. 3.

Firmware Version Online status Internal Event Log Threshold Reached (R) Internal Event Log Wrapped (R) Point Bus Failed since it Last Reported (R)

6. 7. 8. 9.

Valid Local Access (R) RF Receiver Trouble (R) Failed to Call RAM (R) User Code Tamper (R) SDI Device is Failed (R) Receiver Communications Has Failed (R)

4.

10. 11.

5.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 166

SECTION II
12. 13. 14. 15. 16. 17.

FUNCTIONAL REQUIREMENTS
AC Failure (R, DS)
18. 19. 20. 21. 22. 23.

Report Failure (DS) Control Fault (DS) MPX Bus Fault (DS) Radio RX Fault (DS) AUX Power Fault (DS) Option Fault (DS)

Battery is Missing (R) Battery is Low (R, DS) Parameter Checksum Failed (R) Phone Line Failed (R) Extra RF point (R)

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 167

SECTION II

FUNCTIONAL REQUIREMENTS
The status for the intrusion detection zones shall be displayed in Alarm Monitoring (R in parenthesis (R) means Bosch only, DS in parenthesis (DS) means Detection Systems only), G in parenthesis (G) means Galaxy only):
1. 2.

Bypassed/Unbypassed Forced/Not Forced (R, DS) Normal, Shorted, Open, Missing (Not Responding), Not Defined (Not Programmed) Unacknowledged/Ackno wledged (R) Explicit Trouble (DS) Tamper (DS) Low Battery [Radio Zone] (DS) No Signal Strength [Radio Zone] (DS) Alarm (unrestored) (DS, G) Trouble (unrestored) (DS) Untested (DS)

12. 13. 14.

Day Monitor Alarm (DS) Output Latched (DS) Short Circuit Fault (G) Open Circuit Fault (G) Low Resistance (G) High Resistance (G) RF Lid Tamper only RF zones (G) RF Supervision Fail only RF zones (G) RF Low Battery only RF zones (G) RF Zone Fob Deleted only RF zones (G) If the zone is RF or normal (G) Suspended (G)

3.

15. 16. 17. 18.

4.

5. 6. 7.

19.

20.

8.

21.

9.

22. 23.

10. 11.

The status for the intrusion detection areas shall be displayed in Alarm Monitoring (R in parenthesis (R) means Bosch only, DS in parenthesis (DS) means Detection Systems only): Arm/Disarm Status:
1. 2. 3.

Disarmed Not In Use (R, DS) Entire Partition Armed (DS, G) Perimeter Armed (DS)

5. 6. 7. 8.

Master Armed (R) Perimeter Instant Armed (R) Perimeter Delay (R) Area Entry Delay (R) Perimeter Entry Delay (R)

4.

9.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 168

SECTION II
10. 11. 12. 13.

FUNCTIONAL REQUIREMENTS
Area Exit Delay (R) Perimeter Exit Delay (R) Master Armed Instant (R) Setting (G)
14. 15.

Suspend (G) Partial Arm (G)

Additional Area Status:

1. 2. 3. 4. 5. 6. 7.

Not Ready To Arm (R) Area Points Bypassed (R) Area Forced Points (R) Alarm Status (R) System (G) PA Alarm (G) Tamper Alarm (G)

The status for the intrusion detection onboard relays shall be displayed in Alarm Monitoring.
1.

On/Off

The status for the intrusion detection off board relays shall be displayed in Alarm Monitoring.
1.

On/Off

The status for the intrusion detection doors shall be displayed in Alarm Monitoring (Galaxy does not report door status).
1.

Door Mode: Unlocked/Locked (R) Secured/Not Secured (R) Other Door Status: Not Used (R) In Learn Mode/Not in Learn Mode (R) In Diagnostic Mode/Not in Diagnostic Mode (R) In SDI Failure/Not in SDI Failure (R)

2.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 169

SECTION II
Held Open/Not Held Open (R)

FUNCTIONAL REQUIREMENTS

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 170

SECTION II
d) Command and Control Functionality 1) Intrusion Panel Commands

FUNCTIONAL REQUIREMENTS

A command shall be available to set the date and time on the intrusion panel. A command shall also be available to read the date and time on the panel. 2) Zone Commands A command shall be available to bypass a zone. A command shall also be available to unbypass a zone. A command shall be available to turn a zone output on (DS). A command shall also be available to turn a zone output off (DS). 3) Area Commands A command shall be available to arm an area. The possible parameters include: Perimeter Arm (DS) Arms the perimeter of the area. Arm Entire Partition (DS, G) Arms both the interior and perimeter of the area. Master Arm Delay (R) Master (both perimeter and interior) arms (with exit and entry delays) the area. Master Arm Instant (R) Master (both perimeter and interior) arms (no delays) the area. Perimeter Delay Arm (R) Delay arms all perimeter points in the area. Perimeter Arm Instant (R) Instantly arms all perimeter points (no delays) in the area. Partial Arm (G) Partially arms the area, this means that only the zones that have been configured for partial arming will be armed with this command.

A command shall be available to disarm an area. A command shall be available to silence alarms (R). A command shall be available to Cancel/Reset alarms that have occurred for an area (G).

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 171

SECTION II
4) Onboard Relay Commands

FUNCTIONAL REQUIREMENTS

A command shall be available to activate a relay output. A command shall also be available to deactivate a relay output. 5) Off Board Relay Commands A command shall be available to activate an off board relay output. A command shall also be available to deactivate an off board relay output. A command shall be available to toggle an off board relay output (R). 6) Door (Reader) Commands (Galaxy does not support any door commands) A command shall be available to open (cycle) a door (R). A command shall be available to change a door mode (R). The possible parameters include: Unlock Mode Puts the door in an unlocked mode allowing free access. Terminate Unlock Mode Takes a door out of the unlocked mode and places it in the locked mode that requires a proper user ID to allow access. Secure Mode locks down the door so that no access is allowed. Terminate Secure Mode Takes a door our of secure mode and places it in the locked mode which requires a proper user ID to allow access.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 172

SECTION II
e) System Events

FUNCTIONAL REQUIREMENTS

It shall be possible to display events that have occurred on the IDMS panel as well as report any incoming events that occur on the panel while the panel is online. The list of available events for each panel is listed below: 1) Detection Systems DS7400Xi events Fire Alarm Burglary Alarm Keypad Fire Keypad Emergency Keypad Panic Open Close Bypass (24Hr, Fire, Supervisory) Bypass (forced or when closed) Unbypass (24Hr, Fire, Supervisory) Trouble (Zone) Restoral (Zone) Trouble (System) Restoral (System) User Code Change Time Change Date Change Access Code Used Auto Arming Time Change Remote Programming Access Local Programming Access Fire Trouble (Fire or Supervisory Zone) Supervisory Temporary Code Expiration Date Change

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 173

SECTION II
2) Bosch 7412/9412 Events Access Granted Duress User Alarm Bypass Point Forced Point Fire Alarm Fire Trouble Fire Missing Fire Restoral from Alarm Fire Restoral from Trouble Alarm Trouble Restoral from Trouble Missing Alarms Missing Troubles Point Opening Point Closing Extra Point Point Bus Fail All Points Tested Restoral from Alarm Fire Cancel User Code Added Service Start Sensor Reset Relay Set Relay Reset Force Arm Create Status Report

FUNCTIONAL REQUIREMENTS

Fire Walk Start Fire Walk End Walk Test Start Walk Test End Fail Open Fail Close Area Watch Walk Test Point Extend Close Time Non-Fire Cancel Opening Forced Close Closing Test Report Log Threshold Log Overflow Parameter Change User Code Tamper User Code Change Sked Execute Sked Change Date Change Time Change User Level Set Valid Access Invalid Access Valid Remote Invalid Remote Comm Fail

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 174

SECTION II
Comm Restoral Phone Fail Phone Restoral SDI Device Fail SDI Device Restoral AC Fail AC Restoral Battery Missing Battery Low Battery Restoral Watch Dog Reset Supervision (non-fire) Remote Reset Checksum Fail Memory Fail Re-Boot Parameter Checksum Fail Force Perimeter Instant Force Perimeter Delay Perimeter Instant Perimeter Delay Delete User Point Bus Restore RF Battery Low RF Battery Restore RF Tamper Restore RF Receiver Trouble RF Extra Point RF Receiver Restore From Trouble RF Interference

FUNCTIONAL REQUIREMENTS
RF Tamper Alarm RF Tamper Trouble Equipment Restoral Assign Card Delete Card Cycle Door Door Unlocked Door Secured No Entry (Access Denied) Door Left Open Door Request Network Fail Network Restore Network Condition Equipment Fail Fire Supervision Restored Fire Supervision Fire Supervision Trouble Fire Supervision Trouble Restore Extra Account Low Signal Strength RF Receiver Tamper RF Receiver Restore from Tamper RF Interference Restoral Sensor Trouble Sensor Trouble Restore Door Locked Missing Fire Supervision

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 175

SECTION II
Missing Supervision (non-fire) Fail to Execute Analog Service Analog Restore Test Failed External Device Custom Function Executed Low Temperature

FUNCTIONAL REQUIREMENTS
Low Temperature Restore Unverified Event Abort Service Request Output State Output State Restore Bypass Restore Alarm Silenced Alarm Panel Substitution

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 176

SECTION II
f) Bosch 7412/9412 Events Communications Lost Communications Restored Access Granted Access Denied Holdup Alarm Holdup Bypass Holdup Restore Holdup Trouble Holdup Trouble Restore Holdup Unbypass AC Restore Access Lockout Access Trouble Automatic Test Communications Fail Communicatio ns Restore Disarm From Alarm Local Program Local Programming

FUNCTIONAL REQUIREMENTS

Ended Log Threshold Manual Test Parameter Checksum Fail Phone Line Restore Phone Line Trouble Power Up Printer Online Remote Program Begin Remote Program Denied Remote Program Success Schedule Executed System Power Restore System Battery Trouble Test End Test Report Test Start Time Changed Transmitter Battery Restore

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 177

SECTION II
Transmitter Battery Trouble User Code Tamper Fire Alarm Fire Bypass Fire Restore Fire Test Fire Trouble Fire Trouble Restore Fire Unbypass Door Forced Door Forced Trouble Emergency Alarm Emergency Bypass Emergency Restore Emergency Trouble Emergency Trouble Restore Emergency Unbypass Expansion Restore Expansion Trouble Panic Alarm Panic Bypass

FUNCTIONAL REQUIREMENTS
Panic Restore Panic Trouble Panic Trouble Restore Panic Unbypass RF Interference RF Interference Restore Tamper Alarm Tamper Bypass Tamper Restore Tamper Unbypass Untyped Zone Trouble Burglary Alarm Burglary Bypass Burglary Cancel Burglary Restore Burglary Test Burglary Trouble Burglary Trouble Restore Burglary Unbypass

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 178

SECTION II
Burglary Verified Freeze Alarm Freeze Bypass Freeze Restoral Freeze Trouble Freeze Trouble Restore Freeze Unbypass Heat Alarm Heat Bypass Heat Restore Heat Trouble Heat Trouble Restore Heat Unbypass Gas Alarm Gas Bypass Gas Restore Gas Test Gas Trouble Gas Trouble Restore Gas Unbypass Relay Close Relay Open Medical Alarm Medical

FUNCTIONAL REQUIREMENTS
Bypass Medical Restore Medical Trouble Medical Trouble Restore Medical Unbypass Sprinkler Bypass Sprinkler Restore Sprinkler Trouble Sprinkler Trouble Restore Sprinkler Unbypass Sprinkler Alarm Water Alarm Water Bypass Water Restore Water Trouble Water Trouble Restore Water Unbypass Automatic Closing Automatic Opening Close Area

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 179

SECTION II
Closing Extend Closing Report Early Open Fail To Close Late Close

FUNCTIONAL REQUIREMENTS
Late To Open Open Area Opening Report Recent Closing

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 180

SECTION II
g) Status Requirements

FUNCTIONAL REQUIREMENTS

The following list of status reporting shall be included for SYSTEM integration, specific to each panel: Detection Systems DS7400Xi status: Firmware Revision listing. Panel Time Status of all incoming events generated at the panel. Alarm output state Programmable output state Octal relay module state for all relays Arming state for all areas Fire alarm Keypad fire, emergency, medical Burglar zone alarm Supervisory Fire Trouble Fire zone trouble Burglar zone trouble Open Close Forced bypass Bypass Zone restoral Zone trouble restore

The following status shall be retrieved for each zone: Zone active Zone short Zone open Zone in explicit trouble Zone tamper Zone not responding Zone low battery Zone no signal strength Zone not programmed Zone bypassed Zone force bypassed Zone in alarm Zone in trouble Zone untested Zone day monitor alarm Zone output latched

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 181

SECTION II
Bosch 7412/9412 status: 1. Point Status 1) Unacknowledged Alarm Point Status Off Board Relay Status Unacknowledged Supervised Point Status Forced Point Status Unacknowledged Trouble Point Status Bypassed Points Panel Status Area Status Door Status Point Text Galaxy status: Panel Status: Online/offline status of the controller Firmware revision of the controller

FUNCTIONAL REQUIREMENTS

Firmware Revision Point Condition On Board Relay Status User Induced Area Status Transitions Alarm Status for Areas Area Points Not Ready to Arm Area Points Bypassed Area Points Forced Get Panel Time

RF Supervision Fail (only applicable to RF zones) RF Low Battery (only applicable to RF zones) RF Zone Fob Deleted (only applicable to RF zones) Bypassed Alarm (unrestored) Suspended

Zone Status: Whether the zone is normal or RF Open Short Circuit Fault Open Circuit Fault Low Resistance High Resistance RF Lid Tamper (only applicable to RF zones)

Relay Status: Inactive Active Pulse Forced

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 182

SECTION II
Area Status: Disarmed Setting Suspend Entire Partition Armed

FUNCTIONAL REQUIREMENTS
Partial Arm System PA Alarm Tamper Alarm

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 183

SECTION II 9. Asset Management

a) Overview

FUNCTIONAL REQUIREMENTS

The Asset Management System (AMS) shall be available as an integrated solution that is seamlessly integrated with other Total Security Knowledge Management Modules including Access Control & Alarm Monitoring System, Digital Video Management System, Credential Management System, and Visitor Management System. The AMS shall combine powerful transaction based architecture with unique hardware design to deliver real-time asset management, asset tracking and personnel control. The AMS shall be one part of the manufacturers Total Security Knowledge Management Solutions portfolio that utilize Access Control, Credential Management, and Digital Video Management Systems to assign, report, and manage assets within an enterprise using a single distributed database architecture and a common user interface. b) Distributed Decision Making The AMS shall employ a distributed architecture so that all access/asset decisions are made locally at the Intelligent System Controller (ISC). All assets shall be stored locally at the ISC and all decisions to grant asset access shall be made by the local ISC. Absolutely no access/asset decisions shall be made at the HOST or Database Server PC. Even if an Intelligent System Controller is off-line with the Database Server, all asset decisions shall continue to be made and stored in a buffer until communications are restored. c) Asset Technology Independence The AMS shall employ asset technology independence. The AMS shall support multiple asset technologies including Radio Frequency Identification (RFID) and bar-code. d) Multiple Reader Technologies The AMS shall support multiple card reader technologies. The AMS shall support any card reader that outputs a standard Wiegand communications protocol including proximity and bar-code readers. e) Seamless Integration 1) Seamless Integration with Access Control and Alarm Monitoring System The AMS shall seamlessly integrate with the Access Control & Alarm Monitoring System. Asset alarms shall report in the same Main Alarm Monitoring Window as access control alarms and shall be handled in an identical manner. Assets shall be able to move throughout CUSTOMERs facilities based on the access levels of the assigned cardholder.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 184

SECTION II

FUNCTIONAL REQUIREMENTS
The same database MUST store information from both the AMS and the Access Control & Alarm Monitoring System. A separate database for the two systems is unacceptable. 2) Seamless Integration with Digital Video Management System The AMS shall seamlessly integrate with the Digital Video Management System. Any asset alarm/event in the SYSTEM shall have a digital video clip associated with it in real time. Each alarm/event in the SYSTEM shall store a pre-defined number of seconds of video before the event occurred and a pre-defined number of seconds of video after the event occurred. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the AMS and the Digital Video Management System. A separate database for the two systems is unacceptable. 3) Seamless Integration with the Credential Management System The AMS shall seamlessly integrate with the Credential Management System. Assets shall be stored in the SYSTEM database similar to cardholders. Assets shall be assigned to cardholders in the SYSTEM. The cardholders asset rights will determine if an asset can be moved through a checkpoint with that cardholder. The same database MUST store information from both the AMS and the Credential Management System. A separate database for the two systems is unacceptable. 4) Seamless Integration with the Visitor Management System The AMS shall seamlessly integrate with the Visitor Management System. Assets shall be stored in the SYSTEM database similar to cardholders. Assets shall be assigned to visitors in the SYSTEM. The visitors asset rights will determine if an asset can be moved through a checkpoint with that visitor. The same database MUST store information from both the AMS and the Visitor Management System. A separate database for the two systems is unacceptable.

f) Create and Maintain Asset Database A record for each asset shall be created in the Asset Management System by entering the required data into the appropriate data fields. The System Administrator shall be able to define drop-down list box fields for repetitive entered text (e.g.: Asset Type, Cost Center, Department, etc.). Drop-down list boxes shall allow the System Operator a variety of predefined choices for data input. The field design shall be configurable to allow the entry of data in any format desired. The tab order shall be configurable.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 185

SECTION II

FUNCTIONAL REQUIREMENTS

Once all fields have been entered, the AMS shall store the assets record in the SYSTEM database. These records must be stored in a central database. Updating asset data shall be possible at any time by any authorized System Operator. The AMS shall have a field that allows System Administrators to view the last date and time that an assets record has been modified, without running a report. The Asset Form Layout must be user definable. An AMS data import function shall be available to pre-load the AMS with asset records and industry standard image formats of the asset, if desired. This import function shall be capable of adding records to the database at any time. The database shall have key fields that are sorted in an index to allow for faster searches. The System Administrator shall be able to designate fields as required and/or unique fields. No record shall be added to the database that does not contain information within the required fields. No record shall be added to the database that contains a duplicate value in a field that was designated as a unique field. Only System Operators with delete privileges (assigned by the System Administrator) shall be able to delete records. Deleting a record shall permanently remove the record from the database (including image files) to free up the disk space for further use. The AMS shall utilize keyboard or mouse commands that allow System Operators to quickly create a record for any asset. The Asset Form shall also display asset Last Access information for the asset. This field will show the last card reader that the asset accessed or attempted to access, complete with a time and date stamp. For each asset in the AMS, System Operators shall be able to review the assignment history of each person that was previously and currently assigned the asset with the date the asset was assigned and the date the asset was unassigned. System Operators shall be able to assign/re-assign the asset to the current cardholder record with a single click of the mouse. g) Searching Assets The AMS must allow the System Operator to search for assets and images using search criteria on any field(s) in the database. The System Operator must be able to enter the search criteria for one or a combination of fields. In addition, partial searches shall be performed. For example, a partial last name search on Comp might return "Computer, "Computer Keyboard," or "Computer Bag." Using a partial name or letter, shall return every record in the database that contains that information in the asset name field. The AMS shall support basic Boolean logic searches (greater than, greater than or equal to, less than, less than or equal to, equal to). For example, an asset name Boolean Search >B<F will return to the System Operator all assets whose name begins with the letter C, D, and E. These records shall be viewable sequentially using search keys.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 186

SECTION II

FUNCTIONAL REQUIREMENTS

In a query with no matching records, the SYSTEM must display a message within three (3) seconds indicating that there is no match for the key field information supplied. h) Asset Classes/Groups System Administrators shall be able to divide corporate assets into subdivisions called classes. There shall be an unlimited number of classes (limited only by the memory of the ISC) that can be created. An unlimited number of assets shall be able to be assigned to a class. An asset shall be able to be assigned to a minimum of 15 classes. System Administrators shall be able to further divide assets in subdivisions called asset groups. A minimum of 128 assets groups shall be created and up to 64 classes shall be able to belong to a single group. i) Enrollment of Assets System Operators shall be able to enroll assets on a one by one basis. System Operators shall fill in all required fields including name and asset type. If desired, the System Operator shall have the ability to capture an image of the asset. Image capture shall be via live image capture, digital camera, scanner, or file import. j) Assignment of Assets to Cardholders System Operators shall be able to assign/re-assign the asset to the current cardholder record selected with a single click of the mouse. The AMS shall mark a date stamp when the asset was assigned to the cardholder. Cardholders may be assigned to more than one asset. However, and asset may only be assigned to a single cardholder at a time. k) Asset Tracking/Automatic Assignment of Assets to Cardholders System Administrators shall be able to define how assets are handled in the AMS. The AMS shall either be set to Asset Tracking Mode or Automatic Assignment Mode. In Asset Tracking mode, assets shall be tracked through the facility. If a cardholder presents his/her card at the asset reader along with an asset and the cardholder has access to both the asset reader and the asset, the door will open. If the cardholder does not have access to the card reader or the asset, then access through that door will be denied. In Automatic Assignment mode, assets shall be tracked through the facility. This mode shall function similar to Asset Tracking Mode, with the only difference being the ability to automatically assign an asset to cardholders and grant access to them. If a cardholder presents his/her card at the card reader along with an asset, and the cardholder has access to the card reader and is assigned to the asset group in which that asset resides, the door will open and the asset will automatically be assigned to that cardholder. If the cardholder does not belong to the asset group in which the asset resides and is not currently assigned the asset, then access through that door will be denied. l) Asset Tracing From the Main Alarm Monitoring Window, the System Operator must be able to initiate several traces of assets or asset hardware devices while monitoring alarms. This LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 187

SECTION II

FUNCTIONAL REQUIREMENTS

information shall be continuously accumulated in a dedicated trace window until the trace is stopped. The trace operations shall not interfere with the operation of alarm monitoring. The results of each trace shall be printable on a report printer or displayed on the screen. Traces shall operate independently, such that one trace may stop and start without interfering with another. Trace windows operate independently of each other and the Main Alarm Monitoring Window. Thus, different Alarm Filter settings shall be available for each alarm window (Main Window and Trace Windows) open in the Alarm Monitoring module. For example, the Main Alarm Monitoring Window may not monitor Asset Grants Events, while one or more of the trace windows are monitoring Asset Grants Events. The AMS shall support historical traces. Historical traces shall allow System Operators to specify the number of days prior of information that they would like displayed for the particular traced device. For example, a System Operator may perform a historical trace that shows the last seven days activity at a particular asset reader. Events are then added in real-time during and after the database has been searched for historical events. m) Viewing Cardholder Assets System Operators shall be able to perform a search of cardholder records and be able to view all assets that are currently assigned to that cardholder. System Operators shall also be able to perform a search for an asset and view the assignment history of that asset. n) Asset Management Reports There shall be a minimum of six (6) standard AMS reports. All reports MUST be stored in the SYSTEM database and MUST be able to be viewed from any AMS client workstation with proper permissions. The standard reports that shall be included with the AMS are described below: 1) Assets Events The Assets Events Report shall provide information on all asset events that occurred in the AMS. 2) Assets by Scan ID The Assets by Scan ID Report shall provide information on all assets defined in the AMS grouped by Scan ID. 3) Assets by Type The Assets by Type Report shall provide information on all assets defined in the AMS grouped by type and subtype. 4) Assigned Assets by Cardholder The Assigned Assets by Cardholder Report shall provide information on all currently assigned assets, sorted by cardholder. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 188

SECTION II
5) Assigned Assets by Scan ID

FUNCTIONAL REQUIREMENTS

The Assigned Assets by Scan ID Report shall provide information on all currently assigned assets, sorted by Scan ID. 6) Assigned Assets by Type, Scan ID The Assigned Assets by Type, Scan ID Report shall provide information on all currently assigned assets, sorted by type and then Scan ID. o) Bulk Add Mode The AMS shall have a copy command allowing System Operators to easily and efficiently add assets. The copy command shall copy all information configured for an asset selected and apply those same characteristics to the new asset being added. p) Show Assignments 'X' Days Back System Operators shall be able to view an asset's assignment history for a specific period of days from the time of the search. The time period shall be in one day increments. q) On-Line Context Sensitive Help The AMS shall provide on-line context sensitive help files to guide the System Administrators and System Operators in the configuration and operation of the AMS. The help menu shall be available from any window in the AMS by pressing the F1 function key or clicking on the help icon in the toolbar. Help windows shall be context sensitive so System Operators can move from form to form without leaving the help window. Standard windows help commands for Contents, Search, Back, and Print shall also be available. The AMS shall also come with complete on-line documentation on the product disc.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 189

SECTION II 10. Visitor Management

a) Overview

FUNCTIONAL REQUIREMENTS

The Visitor Management System (VMS) shall be available as a standalone solution or as a seamlessly integrated solution with the Access Control & Alarm Monitoring System (SYSTEM), Asset Management System (AMS), Credential Management System (IDMS), and Digital Video Management System (DVMS). All functionality described from this point forward shall reflect functionality of the seamlessly integrated system. The VMS shall allow CUSTOMER to enroll and track visitors of the organization. The VMS shall allow CUSTOMER to enroll visitors, schedule them, assign them to an employee, capture a photo, assign access levels, sign them in or out, and track the visitors as they move throughout the facilities. b) Seamless Integration 1) Seamless Integration with Access Control and Alarm Monitoring System The VMS shall seamlessly integrate with the Access Control & Alarm Monitoring System. Visitors shall have the ability to be assigned access levels and move throughout the facility using their credential. Visitor alarms shall report in the Main Alarm Monitoring Window and shall be logged to the SYSTEM database. The same database MUST store information from both the VMS and the Access Control & Alarm Monitoring System. A separate database for the two systems is unacceptable. 2) Seamless Integration with Asset Management System The VMS shall seamlessly integrate with the Asset Management System. Visitors shall have the ability to be assigned corporate assets. Assets shall be added to, and removed from, visitors and recorded in a detailed audit trail. Visitors generating asset alarms shall trigger those alarms to appear in the Main Alarm Monitoring Window. The same database MUST store information from both the VMS and the Asset Management System. A separate database for the two systems is unacceptable. 3) Seamless Integration with the Credential Management System The VMS shall seamlessly integrate with the Credential Management System. Visitor information shall be stored in the same database as SYSTEM cardholder information. All Visitor fields shall be user definable so that System Administrators shall customize the look and feel of the visitor forms with an off the shelf screen design tool. All visitors shall be assigned and linked to a cardholder record that will be hosting the visitor.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 190

SECTION II

FUNCTIONAL REQUIREMENTS
The same database MUST store information from both the VMS and the Credential Management System. A separate database for the two systems is unacceptable. 4) Seamless Integration with the Digital Video Management System The VMS shall seamlessly integrate with the Digital Video Management System. Any visitor management cardholder alarm/event in the SYSTEM shall have a digital video clip associated with it in real time. Each visitor alarm/event in the SYSTEM shall store a pre-defined number of seconds of video before the event occurred and a pre-defined number of seconds of video after the event occurred. This video clip shall be retrieved at any system Alarm Monitoring client workstation. The same database MUST store information from both the VMS and the Digital Video Management System. A separate database for the two systems is unacceptable.

c) Create and Maintain Visitor Database A record for each visitor shall be created in the VMS by entering the required data into appropriate data fields. The System Administrator shall be able to define drop-down list box fields for repetitive entered text (e.g.: Company Representing, Reason for Visit, etc.). Drop-down list boxes shall allow the System Operator a variety of pre-defined choices for data input. The screen design shall be configurable to allow the entry of data in any format desired. Once all fields have been entered, the VMS shall store the applicant's record in the Access Control & Alarm Monitoring (SYSTEM) database. These records must be stored in a central database. Updating visitor data shall be possible at any time by any authorized System Operator from any client workstation. The visitor form must be user definable to allow System Administrators to layout the visitor form. A data import function shall be available to pre-load the VMS with visitor records and industry standard image formats. This import function shall be capable of adding records to the database at any time. The VMS shall utilize keyboard or mouse commands that allow System Operators to quickly create a record for any visitor. The System Administrator shall be able to define drop-down list box fields for the badge type being issued and default values for the other fields based on the badge type. Once enrolled, a visitor shall not require re-entry of information. Upon a new visit, the visitor's information shall be able to be searched up from the database. d) Searching the Database The VMS must allow the System Operator to search for records and images using search criteria on any field(s) in the database. The System Operator must be able to enter the LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 191

SECTION II

FUNCTIONAL REQUIREMENTS

search criteria for one or a combination of fields. In addition, partial searches shall be performed. For example, a partial last name search on Fitz might return "Fitzpatrick, "Fitzgerald," or "Fitzerbauch." Using a partial name or letter, shall return every record in the database that contains that information in its last name field. The SYSTEM shall support basic Boolean logic searches (greater than, greater than or equal to, less than, less than or equal to, equal to). For example, a last name Boolean Search >B<F will return to the System Operator all records whose last name begins with the letter C, D, and E. These records shall be viewable sequentially using search keys. In a query with no matching records, the SYSTEM must display a message indicating that there is no match for the key field information supplied. e) Enrollment of Visitors System Operators shall be able to enroll visitors on a one by one basis. System Operators shall fill in all required fields including name. System Operators shall have the option to also manually enter a Badge ID for the visitor when scheduling a visit. System Operators will also assign any temporary access levels for each visitor that is enrolled by assigning the visitor a badge type. The VMS shall allow for fast and efficient re-assignment of Badge IDs for use for visitor badges. Re-assignment shall be such that the Badge ID shall be stored in an audit trail and reported with the visitor that was assigned to that Badge ID for the specified period of time. The VMS shall allow the option to add a visit for a visitor at the time of the visitor's enrollment. Visitor information shall be able to be changed at any time. f) Business Card Scanner Enrollment The VMS shall support an integrated business card scanner for automatic population of specific visitor information fields. The VMS shall support the Corex CardScan business card scanner. g) ID Scanner Enrollment The SYSTEM shall support an integrated Drivers License, passport, government ID, and military ID scanner for automatic population of specific visitor information fields, photo, and signature. The VMS shall support the IDScan CSS-800 and CSS-1000 scanners. The SYSTEM shall support bar-code scanning for both scanners.

h) Image Capture from a Live Video Source The client workstation shall include the equipment required to capture a high quality image with flash lighting. The VMS must be compatible with flash lighting, RGB video cameras, composite input cameras, S-Video input sources, and digital cameras. The LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 192

SECTION II

FUNCTIONAL REQUIREMENTS

badging client workstation shall allow the System Operator to view a live image of the subject prior to image capture. While capturing subjects, the System Operator must have the option of capturing a new image of any subject without affecting the subjects record. The VMS must provide the ability to move, via mouse, a fixed-size "crop window" over any portion of the image displayed on the monitor and store only the image information within the outline of the window. The SYSTEM must provide the ability to change the size of the crop window to capture exactly the size image that the CUSTOMER requires. The VMS shall include the ability, upon command, to preview, on-line and in full color, the badge as it will appear when printed. This preview mode shall require less than 10 seconds to create a complete example of the badge on-line. The System Operators shall have the ability to freeze and unfreeze the visitors photo as many times as required to obtain exactly the image that is desired. The frozen image shall not be saved to the database until the cardholder record is saved. VMS image capture, storage, and hardware compression techniques must be in compliance with the ANSI standard or JPEG (Joint Photographic Experts Group). Visitor images must be stored as Binary Large Objects (BLOB) within the cardholder record, regardless of how the image was captured. i) Image Captured from a Scanner or Digital Camera The VMS shall give the System Operators the ability to capture a cardholders image through the use of any industry standard scanner or digital camera that utilizes a TWAIN interface. Images shall be able to be scanned in at up to 16.7 million colors for a true color scanned image. The VMS must provide the ability to move, via mouse, a fixed-size "crop window" over any portion of the image displayed on the monitor and store only the image information within the outline of the window. The VMS must provide the ability to change the size of the crop window to capture exactly the size image that the CUSTOMER requires. The VMS shall include the ability, upon command, to preview, on-line and in full color, the badge as it will appear when printed. This preview mode shall require less than 10 seconds to create a complete example of the badge on-line. VMS image capture, storage, and hardware compression techniques must be in compliance with the ANSI standard or JPEG (Joint Photographic Experts Group). Visitor images must be stored as Binary Large Objects (BLOB) within the cardholder record, regardless of how the image was captured.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 193

SECTION II
j) Image Import

FUNCTIONAL REQUIREMENTS

The VMS shall allow System Operators to import a visitor's image at the time of enrollment. The VMS must support the following image formats: Bitmaps (.bmp, .dib) JPEG (.jpg) JIFF (.jif) Zsoft PCX/DCX (.pcx, .dcx) Adobe Photoshop (.psd) CALS Raster (.cal) GEM/Ventura IMG (.img) IBM IOCA (.ica) WordPerfect Raster (.wpg) Macintosh PICT (.pct) Portable Network Graphic (.png) TIFF (.tif) Windows Metafile (.wmf, .emf) Targa (.tga) Kodak Photo CD (.pcd) Kodak Flashpix (.fpx)

Encapsulated Post Script (.eps) The VMS must provide the ability to move, via mouse, a fixed-size "crop window" over any portion of the image displayed on the monitor and store only the image information within the outline of the window. The VMS must provide the ability to change the size of the crop window to capture exactly the size image that the CUSTOMER requires. The VMS shall include the ability, upon command, to preview, on-line and in full color, the badge as it will appear when printed. This preview mode shall require less than 10 seconds to create a complete example of the badge on-line. The VMS shall give System Administrators the ability to set a default directory of the location of the pre-defined images within the Windows directory structure. VMS image capture, storage, and hardware compression techniques must be in compliance with the ANSI standard or JPEG (Joint Photographic Experts Group). Visitor images must be stored as Binary Large Objects (BLOB) within the visitor record, regardless of how the image was captured. System Administrators shall have the option to set the image capture window default settings of how the image capture window will appear when enrolling cardholders (live video, scanner, or file import). System Operators, with proper privileges, shall have the option to override the VMS defaults. k) Signature Capture The SYSTEM shall allow for System Operators to have the ability to capture a cardholders signature. The SYSTEM shall support any signature pad that supports the Penware or the Wintab interface standards. Signatures shall be displayed on screen and cardholders may sign their name as many times as required to get the signature that is desired. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 194

SECTION II

FUNCTIONAL REQUIREMENTS

Signatures may also be captured by importing a signature file into the SYSTEM or by scanning it in using an industry standard scanning device that utilizes a TWAIN interface. SYSTEM signature capture, storage, and hardware compression techniques must be in compliance with the ANSI standard or JPEG (Joint Photographic Experts Group). Signatures must be stored as Binary Large Objects (BLOB) within the cardholder record. l) Assignment of Visitors to Cardholders Visitors to an organization shall be assigned to a cardholder in the database for the scheduled visit of that visitor. A visitor shall be assigned to more than one cardholder if multiple visits are involved. A cardholder shall have the ability to have multiple visits assigned to them. Before assigning a visitor to a cardholder, System Operators shall have the ability to view the photo of the cardholder from the SYSTEM database as well as view a list of all assigned visitors with their scheduled visit information for that cardholder. System Administrators shall be able to configure which cardholders are authorized to host visitors. m) Scheduling Visits The VMS shall allow System Operators to pre-schedule a visit for a visitor. The information that is recorded for a visit shall be user definable by the System Administrator. Fields that shall be defined include: Visit Time/Date In Visit Time/Date Out Visit Type Purpose of Visit

Visit information shall be able to be modified at any time without having to re-enter the visit information. n) Visitor Sign In/Sign Out Once a visit has been scheduled, the option to Sign In shall be made available. When signing in, a dialog shall prompt the System Operator to optionally print a disposable badge, assign an access control badge to a visitor, and notify the cardholder of the visitor via e-mail. Clicking OK to this dialog shall cause the actual Time In field to be automatically updated. Any configured actions shall also be performed at this time. When the scheduled visitor has been signed in but not signed out, the option to Sign Out shall be made available. When signing out, the actual Time Out field shall be updated and all active badges for the visitor shall be deactivated.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 195

SECTION II

FUNCTIONAL REQUIREMENTS

The VMS shall support bulk sign-in capabilities to allow for batch sign in for all visitors associated with a single visit. The SYSTEM shall support the ability to automatically sign in a visitor by presenting an existing HID proximity visitor card to an OMNIKEY 5125 reader. The badge ID from the card shall be automatically imported into the visitors record and the visitor shall be automatically signed in. The SYSTEM shall support the ability to automatically sign out a visitor by presenting an existing HID proximity visitor card to an OMNIKEY 5125 reader. When a visitor badge is returned and presented to the OMNIKEY 5125 reader attached to the workstation, the visitor shall be automatically signed out and ALL badges assigned to the visitor shall be deactivated regardless of the badge presented. o) Assigning Badge IDs to Visitors The VMS shall allow System Operators to assign a Badge ID to a visitor when scheduling a visit. p) Printing a Visitor Badge The VMS shall allow System Operators the option to print a disposable single-side adhesive visitor badge. The VMS shall support any printer with industry standard and compatible Windows 2008/2003/XP/Vista drivers. The VMS shall support bulk printing capabilities to allow for batch prints for all visit badges associated with a single visit. q) Visit Status User Interface The VMS shall include an advanced Visit Status User Interface, ideal for reception desk or officer checkpoints. The Visit Status UI shall display:
1. 2. 3. 4. 5. 6.

All visits currently in progress (signed-in) Visitors due in during the next user defined minutes Visitors whose visit should have started, but who have not checked in Visits due to expire in the next user defined minutes Overstayed visits Completed Visits

The UI shall automatically refresh with updated information every user defined number of minutes. r) E-mail Integration The VMS shall support an advanced integration with e-mail systems. When scheduling a visit, System Operators shall have the ability to send an e-mail message to one or more LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 196

SECTION II

FUNCTIONAL REQUIREMENTS

recipients that includes the scheduled visit information. Upon changing the initial visit details, an e-mail update shall be sent to all e-mail recipients of the initial visit notification e-mail. s) Visitor Reports There shall be a minimum of four (4) standard VMS reports provided through the browser interface. All reports MUST be stored in the SYSTEM database and MUST be able to be viewed from any VMS client workstation in an HTML format. The standard reports that shall be included with the VMS are described below: 1) All Visitors Report The All Visitors Report shall provide information on all visitors currently enrolled in the SYSTEM. 2) Visit History Report The Visit History Report shall provide information on all visits scheduled in the VMS both past and current. 3) Active Visits by Cardholder Report The Active Visits by Cardholder Report shall provide information on all active visits scheduled sorted by cardholder. 4) Active Visits by Visitor Report The Active Visits by Visitor Report shall provide information on all active visits scheduled sorted by Visitor. t) Screen Designer Tool The VMS shall provide a screen designer tool that allows System Administrators to choose the layout and design of the VMS forms. The following forms shall be available for design and modification: Add/Modify Visitor Form The VMS shall support multiple Visitor Forms. The VMS shall support up to 32 Visitor Forms for creating User Defined Fields. Add/Modify Visits Form The VMS shall support multiple Visit Forms. The VMS shall support up to 32 Visit Forms for creating User Defined Fields.

Database fields for the visitor forms are definable in the SYSTEM forms designer tool. u) Seamless Integration to Credential Management 1) Single Database for Cardholders and Visitors The VMS shall seamlessly integrate with the SYSTEM Credential Management Module. All Visitor records shall be stored in the same database as the cardholder

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 197

SECTION II

FUNCTIONAL REQUIREMENTS
records. System Operators shall have the ability to search for cardholders only, visitors only, or both. When scrolling through records, the Cardholder/Visitor form shall dynamically change based on the type of record displayed. Once enrolled, visitor records shall have the same attributes as Credential Management records. 2) Visitors Record Each visitor shall have his/her own unique record in the SYSTEM database. Each visitor record shall have the following information stored with them. a. User defined fields of visitor information b. Photo c. Current Badge Assigned with Badge Type d. Current Badge Information e. Previous Badge History f. Assigned Access Levels with Expiration Dates 3) Cardholder/Visit Link Each cardholder in the SYSTEM shall have a list of assigned visits that shall list all visit and required visit information. System Operators shall have the ability to choose between viewing all visits or only active visits. System Operators shall have the ability to view the visitor record of a visit with a single mouse click. 4) Visits History A complete visit history shall be stored with each visit, complete with the cardholder visited, time in and out, as well as the purpose of the visit. System Operators shall have the ability to choose between viewing all visits or only active visits. System Operators shall also have the ability to look up the cardholder who is hosting a visit with a single mouse click. 5) Sign In Button The VMS shall have the ability to sign in a visitor with a single mouse click. Signing in a visitor shall mark a time stamp in the SYSTEM database to be used for future audit and reporting purposes. 6) Sign Out Button The VMS shall have the ability to sign out a visitor with a single mouse click. Signing out a visitor shall mark a time stamp in the SYSTEM database to be used for future audit and reporting purposes. System Administrators shall have the ability to pre-define the badge status for 'Signed Out' visitor badges.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 198

SECTION II
v) Visitor Tracing

FUNCTIONAL REQUIREMENTS

The VMS shall trace visitors who are carrying access cards. From the Main Alarm Monitoring Window, the System Operator must be able to initiate several traces of visitors while monitoring alarms. This information shall be continuously accumulated in the dedicated trace window until the trace is stopped. The trace operations must not interfere with the operation of the alarm monitoring. The results of each trace shall be printable on a report printer or displayed on the screen. Traces shall operate independently, such that one trace may stop and start without interfering with another. Trace windows operate independently of each other and the Main Alarm Monitoring Window. Thus, different Alarm Filter settings shall be available for each alarm window (Main Window and Trace Windows) open in alarm monitoring. For example, the Main Alarm Monitoring Window may not monitor Access Grants Events, while one or more of the trace windows are monitoring Access Grants Events. The VMS shall support historical traces. Historical traces shall allow System Operators to specify the number of days prior of information that they would like displayed for the particular visitor that is being traced. For example, a System Operator may perform a historical trace that shows the last seven days activity of a particular visitor. Events are then added in real-time during and after the database has been searched for historical events. w) Pre-Defined Badge Formats The badge format, including layout, background color, location of photo, text, applicable graphics or company logos, etc., shall be completely and automatically determined by the VMS based on the cardholders badge type. Where choices are available to the System Operator, choices are to be made via pre-defined list boxes to avoid System Operator errors in spelling and badge assignment errors. x) On-Line Context Sensitive Help The VMS shall provide on-line context sensitive help files to guide the System Administrators and System Operators in the configuration and operation of the VMS. The help menu shall be available from any window in the VMS by pressing the F1 function key or clicking on the help icon in the toolbar. Help windows shall be context sensitive so System Operators can move from form to form without leaving the help window. Standard windows help commands for Contents, Search, Back, and Print shall also be available. The VMS shall also come with complete on-line documentation on the product disc. y) Browser-based Visit Host Application The SYSTEM shall provide a browser-based visit host application. The browser-based visit host application shall utilize n-tier architecture. The browser-based visit host application shall support single sign-on.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 199

SECTION II

FUNCTIONAL REQUIREMENTS

The browser-based visit host application shall be able to provide three distinct functions: registration of visitors, scheduling events, and visit calendar. The browser-based visit host application shall allow for the registration of new visitors by the SYSTEM USER. The SYSTEM USER shall be able to create a new visitor and enter demographic information about the visitor, including first name, last name, address, and phone number. The SYSTEM shall allow for the SYSTEM USER to add additional user defined fields to the list of demographics fields. The visitor and the visitors information shall be saved on the SYSTEM database and shall be able to be utilized by other components of the SYSTEM. The browser-based visit host application shall allow for registration of visits for the SYSTEM USER. The SYSTEM USER shall be able to create a new visit, specifying event name, event date, event time, and event purpose. The SYSTEM shall allow for additional fields to be added to the visit information fields. The SYSTEM ADMINISTRATOR shall be able to make additional fields required fields. The SYSTEM USER shall be able to search for a visitor in the SYSTEM to schedule the visitor for the visit. Upon selecting the visitor and scheduling the visit, this information shall be saved to the SYSTEM database. The browser-based visit host application shall allow for the scheduling of events. The SYSTEM USER shall be able to invite up to seventy-five (75) visitors per event. The browser-based visit host application shall provide a visit calendar that shall keep track of all visits the SYSTEM USER has scheduled. The calendar shall also provide status of the visitor associated with the visit, specifically if the visitor is, scheduled, late, onsite, overstayed, or signed out. The browser-based visit host application shall display group events in the visit calendar. It shall display the number of visitors invited to the group event. The browser-based visit host application shall support the designation and management of delegates. The delegate shall be able to schedule a visit on behalf of other hosts. The browser-based visit host application shall have an advanced search that shall be able to search for delegates, hosts, invited visitors, and user defined fields. z) Smart Client Based Front Desk application The SYSTEM shall provide a smart client based front desk application. The smart client based front desk application shall utilize n-tier architecture. The SYSTEM USER shall be able to add a new event. The SYSTEM USER shall be able to invite at least seventy-five (75) visitors per event. The SYSTEM USER shall be able to modify the host of an event. The SYSTEM USER shall be able to remove a scheduled event. The SYSTEM USER shall be able to add or remove the invited visitors of an event. The SYSTEM USER shall be able to modify the scheduled time in/out of an event. The SYSTEM USER shall be able to modify the name of an event. The SYSTEM USER shall be able to add a new visitor. The SYSTEM USER shall be able to view/modify/delete/sign-in in a visit scheduled from the SYSTEM. The SYSTEM USER shall be able to modify an event and the SYSTEM shall prompt the SYSTEM USER to

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 200

SECTION II

FUNCTIONAL REQUIREMENTS

define a location for a visit originally scheduled in the SYSTEM. The SYSTEM ADMINISTRATOR shall be able to create and modify user defined fields of an event. The SYSTEM USER shall be able to scan a visitors business card using a business card scanner. The smart client based front desk application shall capture the information on the card and use it to populate the SYSTEM fields with the appropriate visitor information. The smart client based front desk application shall automatically search for visitors based on the Last Name that was scanned in from the business card. If the visitor is not found during the automatic search, then the smart client based front desk application shall use the scanned business card information to add a new a visitor to the SYSTEM. The SYSTEM USER shall be able to take a photo from a camera supporting the WDM interface. The SYSTEM USER shall be able to manually assign an active credential to a visitor providing the visitor the ability to utilize the badge as a full functioning access control credential. The smart client based front desk application shall have the option of sending an email to the visitor upon the successful scheduling of the visit. The email shall contain a unique visit identification number that can be displayed as both a barcode and a numerical value. The SYSTEM USER shall be able to configure a default printer. The smart client based front desk application shall be able to print a disposable badge either in portrait or landscape format. The smart client based front desk application shall be able to print user defined fields on the badge. The smart client based front desk application shall be able to adjust for printing different fonts and colors. The smart client based front desk application shall support scale text to fit. The smart client based front desk application shall be able to print graphics in their original aspect ratio. The smart client based front desk application shall be able to print a barcode value on a badge. The smart client based front desk application shall be able to print signatures. The smart client based front desk application shall support the SYSTEMs Badge Designer layouts and the ability to print them. The SYSTEM USER shall be able to install the smart client based front desk application installation component during the SYSTEMs installation on a server so that it can be deployed on desired client machines automatically. The SYSTEM USER shall be able to access the online help. aa) Kiosk application The SYSTEM shall provide a kiosk application, (KIOSK), with the purpose of providing visitor self-service for signing in and signing out. The kiosk shall utilize n-tier architecture. The KIOSK shall be designed to be used with a touch screen. The KIOSK shall provide a predefined workflow for the process of signing in a visitor.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 201

SECTION II

FUNCTIONAL REQUIREMENTS

The system administrator shall be able to use single sign-on in order to sign onto the KIOSK. The system administrator shall be able to select a name for the kiosk, add sign-in locations, assign time zones, add and configure kiosk profiles, and assign kiosks to profiles. The KIOSK shall provide the option of signing in visitors by allowing the visitor to provide a unique visit identification number that shall be generated by the SYSTEM visitor management applications. Each visit identification number shall only be valid for a single visit. Upon acceptance of a valid visit identification number the kiosk shall proceed to the next step in the workflow. The KIOSK shall provide the option for a visitor user agreement that shall be fully customizable during SYSTEM configuration. The visitor user agreement shall be capable of taking the form of a non-disclosure agreement or liability wavier. The SYSTEM shall offer complete audit trail capabilities of a signed visitor user agreement. Visitor user agreements shall not be capable of being modified by visitors. Visitor user agreements shall be confirmed by the visitor with a check box. The KIOSK shall allow for the visitor to enter in demographic information as part of the visitor sign in workflow. The KIOSK shall allow for fully user definable fields. Information shall be entered into the KIOSK through a touch screen interface where a touch screen keypad shall appear on the screen when selecting fields. The KIOSK shall allow for fields to be required. All information entered into the KIOSK shall automatically report back to the SYSTEM database. The KIOSK shall provide the ability to take a photograph of the visitor. Once the KIOSK takes a photograph it shall have the ability to auto-crop the photograph of the visitor. The KIOSK shall provide the option for the visitor to re-take the photograph. The KIOSK shall provide a preview of the visitor credential before printing. The visitor credential shall be fully customizable by the SYSTEM USER. The visitor credential shall be able to contain a bar code of the visit identification number. The KIOSK shall be able to print the visitor credential. Upon completion of the KIOSK sign in workflow, the SYSTEM shall now report the visitor as signed in to the SYSTEM. The KIOSK shall provide the ability for a visitor to sign themselves out of the SYSTEM. Signing out shall be completed by selecting the sign out option and providing the visit identification number in either a numerical or bar code form. After selecting the sign out option, the SYSTEM shall report the visitor as signed out of the SYSTEM. The kiosk application shall integrate with a barcode scanner for the purpose of scanning in a visit identification number from a barcode. The KIOSK shall print wearable, disposable, peel and stick visitor badges. The Kiosk shall integrate with the Logitech

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 202

SECTION II

FUNCTIONAL REQUIREMENTS

QuickCam Orbit AF camera for the purpose of taking a photograph of the visitor during the sign in process. bb) Visitor Administration application The SYSTEM shall provide a visitor administration application. The visitor administration application shall utilize n-tier architecture. The visitor administration application shall allow the management of locations. It shall allow the addition of sign-in locations. It shall allow the modification of sign-in locations. It shall allow the system administrator to delete sign-in locations. It shall allow the modification of Kiosk profiles. The system administrator shall be able to configure the text in the confirmation email that is sent to the invited visitor. The system administrator shall be able to manage the badge type of the disposable badges. The system administrator shall be able to access help and documentation that will provide instructions on how to install, setup, configure, and upgrade the visitor administration application.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 203

SECTION II 11.Remote Access Level Management

a) Overview

FUNCTIONAL REQUIREMENTS

The Area Access Manager (AAM) shall be available as an integrated solution that is seamlessly integrated with the Access Control & Alarm Monitoring System and the Credential Management System. The AAM shall be a technology that allows CUSTOMER to assign and remove access levels to/from cardholders in the existing SYSTEM database. b) Seamless Integration 1) Seamless Integration with Access Control and Alarm Monitoring System The AAM shall seamlessly integrate with the Access Control & Alarm Monitoring System. System Operators shall be able to assign and remove access levels to/from cardholders that already exist in the SYSTEM database. Access level changes automatically occur in the database and are simultaneously sent to all Intelligent System Controllers that are affected. Access level changes shall immediately take effect and shall be viewable from any other client workstation on the SYSTEM. 2) Seamless Integration with the Credential Management System The AAM shall seamlessly integrate with the Credential Management System. System Operators shall be able to search up records from the SYSTEM database for the assigning and removing of access levels. c) Password and Permission Privileges The AAM shall allow System Administrators to configure individual System Operator passwords that restrict which System Operators shall have access to the Access Level Manager. System Administrators shall have the ability to limit which access levels a System Operator is allowed manage. For example, a system may have 200 access levels configured. System Operator A will have the ability to assign and remove 20 of the access levels from a SYSTEM cardholder, while System Operator B will have the ability to assign and remove 3 of the access levels from a SYSTEM cardholder. Passwords shall not print in any report. d) Browser Based Remote Access Level Management The SYSTEM shall provide a web-browser based Area Access Manager Client allowing any computer with Internet Explorer 6.0 or 7.0 and meeting other minimum requirements to perform access level management remotely. The browser based remote access level management shall provide the same primary functionality as a rich client. The browser based remote access level management shall use an N-tier architecture.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 204

SECTION II

FUNCTIONAL REQUIREMENTS

e) Viewing Current Access Level Assignments Upon logging in, a dropdown list shall list all of the access levels that the System Operator is allowed to manage. Selecting an item from this list shall automatically display the cardholders in the SYSTEM (with First Name and Last Name) that currently have that access level assigned to them. A counter shall also display showing the total number of cardholders who are assigned that access level. System Operators shall view the cardholder photo as well as view a list of all cardholder badges that are currently assigned the access level. The SYSTEM USER shall have the ability to have view-only access to the Area Access Manager application. f) Removing Access Level Assignments System Operators shall remove access levels from SYSTEM cardholders. System Operators shall select an access level to view all cardholders who are assigned that access level. System Operators shall then have the ability to simultaneously remove one or multiple cardholders from that access level. A counter shall be available to show how many cardholders have been selected for removal of the access level. Removing access levels shall automatically propagate those removals to the Intelligent System Controllers. g) Assigning Access Levels System Operators shall assign access levels to SYSTEM cardholders. If multiple active badges per cardholder is in use, System Operators shall be able to assign access levels to one or more of the active cardholder badges. System Operators shall select an access level to view all cardholders who are assigned that access level. System Operators shall then have the ability to assign one or multiple cardholders to that access level. The AAM shall allow System Administrators the ability to assign activation and deactivation dates to each access level, thus giving a date when the access level will become active and a date when the access level will no longer be valid. A counter shall be available to show how many cardholders have been selected for assignment of the access level. Assigning access levels shall automatically propagate those assignments to the Intelligent System Controllers. h) Temporary Access Level Assignments System Operators shall be able to assign temporary access levels to cardholders for special occasions or visitor privileges, giving them temporary access to specific card readers. The AAM shall allow System Administrators the ability to assign activation and deactivation dates to each access level, thus giving a date when the access level will become active and a date when the access level will no longer be valid. Temporary access levels shall be stored in the ISC, such that they function properly in the event the ISC is off-line with the database server. i) Bulk Assignment of Activate/Deactivate Dates to Access Levels AAM shall have the ability to bulk modify activate/deactivate dates on access level assignments to cardholders in order to grant or remove access to a group of cardholders at a specific date and time. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 205

SECTION II

FUNCTIONAL REQUIREMENTS

The Activation/Deactivation dates shall not assigned directly to the access level, but rather to each cardholder (badge) access level assignment. Thus, it shall possible to have different activate/deactivate dates for the same access level that is assigned to individual badges. j) Associated Video The SYSTEM shall allow for video that is linked with doors associated with AAM levels to be viewed through AAM. k) Remote Access Level Management Reports There shall be a minimum of two (2) standard Remote Access Level Management reports provided with AAM. All reports MUST be stored in the SYSTEM database and MUST be able to be viewed from any AAM client workstation. The standard reports that shall be included with the AAM are described below: 1) Cardholders Authorized to an Area Report The Cardholders Authorized to an Area Report shall provide information on all authorized cardholders that have access to an area that the AAM Operator controls. 2) Access Level Assignment Report The Access Level Assignment Report shall provide information on all access levels assigned to each cardholder. The report shall only contain information on access levels that the currently logged AAM Operator has permission to manage. l) On-Line Context Sensitive Help The AAM shall provide on-line context sensitive help files to guide the System Administrators and System Operators in the configuration and operation of the AAM. The help menu shall be available from any window in the AAM by pressing the F1 function key or clicking on the help icon in the toolbar. Help windows shall be context sensitive so System Operators can move from form to form without leaving the help window. Standard windows help commands for Contents, Search, Back, and Print shall also be available. The SYSTEM shall also come with complete on-line documentation on the product disc.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 206

SECTION II 12.Third Party Interfaces

a) Overview

FUNCTIONAL REQUIREMENTS

The Total Security Knowledge Management Solutions shall support multiple seamlessly integrated third party interfaces with hardware and software vendors. These interfaces shall be integrated such that the interfaces utilize a single graphical user interface, single source code base, and a single database for configuration, alarm, and event storage. The interface shall allow data to be organized for optimum performance with one application accessing a single bank of data. Any changes to system hardware shall be instantly available across the entire SYSTEM. Interfaces using separate databases with information being exchanged by 'data sharing' shall be unacceptable. b) OPC Server Support The SYSTEM shall support an OPC Server designed to OPC standards for Building Automation/Process Control Systems. The SYSTEM OPC Server shall allow any and all SYSTEM alarms and events to be routed in real time to any industry standard OPC Client (such as a building automation or process controls monitoring workstation) for centralized reporting of alarm activity. c) OPC Client Support The SYSTEM Alarm Monitoring Workstation shall be able to function as an OPC Client designed to OPC standards for Building Automation/Process Control Systems. The SYSTEM OPC Client shall be able to accept any and all Building Automation/Process Control Systems alarms and events sent via OPC Standards for Alarm and Events that are routed in real time from any industry standard OPC Server (such as a building automation or process controls monitoring workstation) for centralized reporting of alarm activity. Once inside the SYSTEM Alarm Monitoring Workstation, the OPC alarm and events shall act just like standard SYSTEM alarms and events and can be linked with global input/output activity, digital video, etc. d) SNMP Support SNMP (Simple Network Management Protocol) shall be used for managing and monitoring devices on a network. The device that is being managed or monitored shall be called the Agent. The application that is doing the managing or monitoring shall be called the Manager. Trap messages shall be generated by an Agent and sent to a Manager to indicate that something has changed. The SYSTEM shall use these trap messages to send alarms to SNMP Managers. 1) SNMP Agent Support The SYSTEM SNMP Agent shall provide seamless integration with SNMP client applications. SYSTEM events shall be sent from the SYSTEM to be received by

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 207

SECTION II

FUNCTIONAL REQUIREMENTS
any SNMP monitoring application. SYSTEM events shall be delivered to SNMP managers through the use of SNMP traps. 2) SNMP Manager Support The SYSTEM SNMP Manager shall provide seamless integration with SNMP client applications. The SYSTEM shall receive events from any SNMP Agent application via SNMP traps and shall process them just like any traditional alarm in the system, including providing linkages to digital video and global I/O functionality.

e) IBM WebSphere Adapter The SYSTEMs IBM WebSphere Adapter shall provide a seamless, real time interface to IBMs WebSphere Messaging System. This advanced feature shall leverage SYSTEMs architecture for open connectivity with IBMs WebSphere architecture for reliable messaging interfaces to deliver an advanced integration point between the two systems. SYSTEMs IBM WebSphere Adapter shall allow any and all SYSTEM alarms and events to be routed in real time to IBM WebSphere for processing. Based on the alarm, IBM WebSphere will then generate messages to be sent throughout the enterprise using their delivery vehicles. f) Microsoft Queues Adapter The SYSTEMs Microsoft Queues Adapter shall provide a seamless, real time interface to Microsoft Queues Messaging System. This advanced feature shall leverage SYSTEMs architecture for open connectivity with Microsoft Queues architecture for reliable messaging interfaces to deliver an advanced integration point between the two systems. SYSTEMs Microsoft Queues Adapter shall allow any and all SYSTEM alarms and events to be routed in real time to Microsoft Queues for processing. Based on the alarm, Microsoft Queues will then generate messages to be sent throughout the enterprise using their delivery vehicles. g) Fire Alarm Interface The SYSTEM shall support a seamlessly integrated fire alarm interface. The fire alarm interface shall support the following fire panels:
1. 2. 3. 4. 5.

Pyrotronics MXL fire panel Pyrotronics MXL-IQ fire panel Notifier AM2020 fire panel Notifier NFS-640 fire panel Any fire panel that supports the European Standard ESPA 4.4.4 protocol

The fire alarm panels shall be configured in the SYSTEM configuration and administration module. For each fire panel, an alphanumeric name of up to 32 characters LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 208

SECTION II

FUNCTIONAL REQUIREMENTS

shall be given for alarm monitoring and reporting purposes. System Administrators shall be able to configure a serial port and client workstation that the panel is connected to, as well as communications speed. System Administrators shall have the ability to group add, modify, and delete fire panels in the SYSTEM. The SYSTEM shall have a copy command, allowing System Administrators to easily and efficiently add fire panels. The copy command shall copy all information configured for a fire panel selected and apply those same characteristics to the new fire panel being added. System Administrators will also have the ability mark fire panels as on-line or off-line depending on whether those panels are on-line. The fire alarm interface shall allow for secondary annunciation of fire alarm alarms in the Main Alarm Monitoring Window. Fire alarms reporting into the Main Alarm Monitoring Window shall report just like any other access control alarm and shall have the same annunciation and display properties as access control alarms (See Section II, Number 2, Bullets b and c). All fire alarms and events that report into the SYSTEM shall be stored in the SYSTEM database for future audit trail and reporting capabilities. h) Intercom Interface The SYSTEM shall support a seamlessly integrated intercom interface. The intercom interface shall support the following intercoms:
1. 2. 3.

Zenitel AlphaCom Zenitel AlphaNet Ericsson MD110 PBX

The intercom panels shall be configured in the SYSTEM configuration and administration module. For each intercom panel, an alphanumeric name of up to 32 characters shall be given for alarm monitoring and reporting purposes. System Administrators shall be able to configure a serial port and client workstation that the panel is connected to, as well as communications speed. The SYSTEM shall have a copy command, allowing System Administrators to easily and efficiently add intercom panels. The copy command shall copy all information configured for an intercom panel selected and apply those same characteristics to the new intercom panel being added. System Administrators will also have the ability mark intercom panels as on-line or off-line depending on whether those panels are on-line. Intercom Stations shall be configured in the SYSTEM configuration and administration module. For each intercom station, an alphanumeric name of up to 32 characters shall be LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 209

SECTION II

FUNCTIONAL REQUIREMENTS

given for alarm monitoring and reporting purposes. System Administrators shall be able to configure the intercom panel it is connected to as well as an intercom station number. System Administrators shall be able to program into the SYSTEM a list of intercom functions that report into the alarm monitoring module. These functions shall coincide with the intercom functions provided with the Stento Alpha Com system. For each intercom function, System Administrators shall be able to define the function with a logical name of up to 32 alphanumeric characters and shall also be able to set the parameter value of that function. The intercom interface shall allow for secondary annunciation of intercom calls, events, and alarms in the Main Alarm Monitoring Window. Intercom reporting into the Main Alarm Monitoring Window shall report just like any other access control alarm and shall have the same annunciation and display properties as access control alarms (See Section II, Number 2, Bullets b and c). All intercom, calls, events, and alarms that report into the SYSTEM shall be stored in the SYSTEM database for future audit trail and reporting capabilities. For the Ericsson MD110 PBX switch: A System Operator shall be able to place a call by right clicking on a device. A System Operator shall be able to cancel all calls for a device by right clicking on a device. A System Operator shall be able to cancel a single call by right clicking on the Ringing, Call Established, Transferred Call, or Conferenced Call alarm for the call. The System Operator shall be able to divert queued calls. A System Operator shall be able to display events when a device is placing a call. A System Operator shall be able to block a device for calls. A System Operator shall be able to display blocked state for devices. A System Operator shall be able to link events to SYSTEM options/ A System Operator shall be able to answer a pending call by right clicking on the Ringing alarm for the call. A System Operator shall be able to update hardware status by selecting this from the right-click menu for the MD110 intercom exchange. i) Point of Sale Interface The SYSTEM shall support a seamlessly integrated point of sale interface. The point of sale interface shall be with the Transaction Verification Systems TVC-2100 series point of sale systems. The point of sale equipment shall be configured in the SYSTEM configuration and administration module. For each cash register, an alphanumeric name of up to 32 characters shall be given for alarm monitoring and reporting purposes. System Administrators shall be able to configure a serial port and client workstation that the register is connected to, as well as communications speed. The SYSTEM shall have a copy command, allowing System Administrators to easily and efficiently add point of sale registers. The copy command shall copy all information LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 210

SECTION II

FUNCTIONAL REQUIREMENTS

configured for a point of sale register selected and apply those same characteristics to the new point of sale register being added. System Administrators will also have the ability mark point of sale registers as on-line or off-line depending on whether those panels are on-line. The point of sale interface shall allow for secondary annunciation of point of sale registers activity in the Main Alarm Monitoring Window. Point of sale register event reporting into the Main Alarm Monitoring Window shall report just like any other access control alarm and shall have the same annunciation and display properties as access control alarms (See Section II, Number 2, Bullets b and c). For example, a digital video clip may be locked and associated with a cash register event. All point of sale registers events, and alarms that report into the SYSTEM shall be stored in the SYSTEM database for future audit trail and reporting capabilities. j) Personal Safety System Interface The SYSTEM shall support a seamlessly integrated personal safety system interface. The personal safety system interface shall be with the Visonic SpiderAlert personal safety system. The SpiderAlert panels shall be configured in the SYSTEM configuration and administration module. For each SpiderAlert panel, an alphanumeric name of up to 32 characters shall be given for alarm monitoring and reporting purposes. System Administrators shall be able to configure a serial port and client workstation that the panel is connected to, as well as communications speed. System Administrators shall have the ability to group add, modify, and delete SpiderAlert panels in the SYSTEM. The SYSTEM shall have a copy command, allowing System Administrators to easily and efficiently add SpiderAlert panels. The copy command will copy all information configured for a SpiderAlert panel selected and apply those same characteristics to the new SpiderAlert panel being added. System Administrators will also have the ability mark SpiderAlert panels as on-line or off-line depending on whether those panels are on-line. System Administrators shall be able to configure transmitters for the personal safety system interface. The transmitters shall be configured in the SYSTEM configuration and administration module. For each transmitter, an alphanumeric name of up to 32 characters shall be given for alarm monitoring and reporting purposes. System Administrators shall be able to configure the base ID of the transmitter as well as the transmitter type. The following transmitter types shall be available for configuration: Handheld 1 Button Handheld 2 Button Handheld 4 Button Magnetic Contact Man Down Man Down RF Pendant Pendant, Dual Technology

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 211

SECTION II
PIR Detector Spatial Position Detector Universal Transmitter. 2 Inputs

FUNCTIONAL REQUIREMENTS
Wristband, Waterproof Smoke Detector

System Administrators shall be able to configure the transmitters to report events such as Restore, Supervision, and Tamper where applicable. They shall also have the ability to define when alarms from the transmitters shall be masked. Transmitters shall be able to be assigned to SYSTEM cardholders or assets for alarm monitoring and reporting purposes. System Administrators shall be able to program the transmitter inputs. Transmitter inputs shall coincide with the transmitter types configured. For each transmitter input, System Administrators shall be able to define a logical name of up to 32 alphanumeric characters. Transmitter input shall be able to be assigned to SYSTEM cardholders or assets for alarm monitoring and reporting purposes. The SYSTEM shall have the ability to program and send command data to downstream devices. The following device types shall be available for transmission: SpiderBus Controller (SLC-5) 8 Output Transmitter (SI-540) 4 Input, 4 Output Interface (SI-544) Wireless Receiver (SR-500) Dual Technology Receiver (SR-520) Dual Technology Receiver (SR-521) Dual Technology Receiver (SR-522) SpiderBus Repeater (SRP-51)

System Administrators shall have the ability to set Device IDs and send other commands to each of the above devices. The Personal Safety interface shall allow for secondary annunciation of Personal Safety calls, events, and alarms in the Main Alarm Monitoring Window. Personal Safety alarms reporting into the Main Alarm Monitoring Window shall report just like any other access control alarm and shall have the same annunciation and display properties as access control alarms (See Section II, Number 2, Bullets b and c). All Personal Safety, calls, events, and alarms that report into the SYSTEM shall be stored in the SYSTEM database for future audit trail and reporting capabilities.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 212

SECTION II
k) Central Station Alarm Receiver Interface

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support a seamlessly integrated central station alarm receiver interface. Central station alarm receivers shall be configured in the SYSTEM configuration and administration module. For each receiver, an alphanumeric name of up to 32 characters shall be given for alarm monitoring and reporting purposes. System Administrators shall be able to configure a serial port and client workstation to which the receiver is connected, as well as communication speed. The SYSTEM shall support the following central station receivers:
1. 2. 3. 4.

Bosch 6500/6600 Digitized 3500/3505 Osborne Hoffman OH-2000 AES Intellinet (receivers that support the Bosch 6500 Output Mode)

System Administrators shall have the ability to group modify and delete receivers in the SYSTEM. The SYSTEM shall have a copy command, allowing System Administrators to easily and efficiently add receivers. The copy command shall copy all information configured for a receiver selected and apply those same characteristics to the new receiver being added. System Administrators shall also have the ability to mark receiver panels as on-line or off-line depending on whether those panels are on-line. System Administrators shall be able to configure many types of different alarm panels with the receiver to report alarms. Each panel shall be assigned an account number and may have additional information added such as name, address, notes, etc. System Administrators hall have the ability to assign named zones and areas to these accounts as well as event codes. The receiver interface shall allow for primary and/or secondary annunciation of receiver events and alarms in the Main Alarm Monitoring Window. Receiver reporting into the Main Alarm Monitoring Window shall report just like any other access control alarm and shall have the same annunciation and display properties as access control alarms (see Section II, Number 2, Bullets b and c). All receiver events and alarms that report into the SYSTEM shall be stored in the SYSTEM database for future audit trail and reporting capabilities. l) Smart Card Readers The SYSTEM shall support the ability to integrate with Omnikey Smart card readers. The purpose of this integration shall be to provide logical security. This integration shall allow CUSTOMER another option to read and encode contact smart card when working with various contact smart card encoding formats. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 213

SECTION II
m) Smart Card Life Cycle Management

FUNCTIONAL REQUIREMENTS

The SYSTEM shall provide the ability to manage the life cycle of a smart card through integration with ActivIdentity. The integration shall provide the ability to personalize contact smart cards during the badge issuance process in the SYSTEM, propagate badge life cycle events including, but not limited to, badge encoding, activation, deactivation, and deletion. This integration shall provide solutions to allow use of a single card for both physical and logical access control. The integration shall provide the ability to ensure consistent card state between physical and logical access control system. The integration shall provide the ability to use a single interface for issuance of the physical/logical access card. n) Otis Compass Destination Entry System Elevator Interface The SYSTEM shall be able to interface with Otis Compass Destination Entry System. This interface shall provide secure, optimized access to banks of elevators. The SYSTEM shall verify the cardholders access privileges upon their arrival to an access point and their presentation of their credential. Upon this verification the SYSTEM shall communicate with the dispatching system to identify the floor(s) that the card holder is permitted, as well as determining the default floor for the cardholder. The SYSTEM shall then direct the cardholder to a designated elevator car for secure access to their default or selected floor. The SYSTEM shall also allow for a custom person type descriptor to be passed from the SYSTEM to the destination dispatching system, this is in addition to the access permissions, default floor, and the disability flags. o) Barco Integration The SYSTEM shall support a Steaming Video Server (SVS) that shall be installed when installing the SYSTEMs video software. The SVS shall be able to retrieve live video from any MANUFACTURER Video Recorder that supports the video search feature and then project the video onto a Barco Video wall. The SYSTEM shall be able to change the Barco Wall layout to any layout that has been configured on the Barco Wall Controller. This shall be able to be done manually through the SYSTEM, based on a SYSTEM event or based on the SYSTEM scheduler. p) Onity Integra Offline Locks Integration Overview The SYSTEM shall allow configuration of Onity Integra offline locks and the Onity XPP portable programmer. In an Onity configuration the SYSTEM shall act as a front end to the Onity data which is transferred between the SYSTEM and the Onity locks via the XPP portable programmer. Configuration Configuring Onity locks in the SYSTEM shall require the use of the Onity XPP portable programmer, which is used to transfer data from the SYSTEM to the Onity locks and vice LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 214

SECTION II

FUNCTIONAL REQUIREMENTS

versa. To configure Onity locks in the SYSTEM an offline controller shall first be added and the locks shall be defined which shall then be configured via the XPP portable programmer. The SYSTEM shall support the ability to add at a minimum 1024 locks to an Onity controller. The SYSTEM USER shall be able to gain access by swiping a credential or inputting a PIN into a locking unit. The SYSTEM shall support sending up to thirty (30) time zones and up to five thousand (5,000) users information to the lock. The SYSTEM shall support sending up to twenty (20) automatic changes to the lock. The SYSTEM shall support sending holidays and DST to the lock. The SYSTEM shall support Onity Integra Controller Configuration. An Onity Integra form shall be present on the Access Panels folder. The SYSTEM USER shall be able to add, modify, and delete the Onity controller. Only one controller (panel) is allowed per the system. The SYSTEM USERS shall be able to configure a Name of up to thirty-two (32) characters. The SYSTEM USERS shall be able to configure an Online parameter that indicates that the panel is ready to use. The SYSTEM USERS shall be able to configure Location information: Workstation (location of the Communication Server), World Time Zone, and Daylight savings setting. The SYSTEM USERS shall be able to configure Options information: PIN length (values 4 7, default is 4); Login attempts (values 1 20, default is 3); Auto logout (values on/off, default is off); Idle time (values 1 120 minutes, default is 10); Deactivate data (values on/off, default is off); Deactivate time (values 1 120 days, default is 30); and Number of events/audits locks can hold. The SYSTEM USER shall be able to establish the number of users and length of card data and the software will compute the number of audit trail transactions. The SYSTEM shall support configuring Onity Alternative Fire Code (AFC) Settings on a System-wide basis in System Options. Lock Panel The SYSTEM OPERATOR shall be able to add an Onity Offline Lock Panel. The Onity Offline Lock Panel shall refer to a XPP portable programmer. The SYSTEM OPERATOR shall be able to type in a unique, descriptive name for the offline lock panel and configure the configuration parameters such as the workstation, COM port, and password. Onity Reader The SYSTEM OPERATOR shall be able to add an Onity Reader. The SYSTEM OPERATOR shall be able to type in a unique, descriptive name for the reader, select the access panel the reader connects to, select Stand Alone Lock, and configure the rest of the options on the form. The SYSTEM OPERATOR shall be able to configure the Onity system options. The Onity system options shall allow configuration of data elements that affect the programming of all Onity controllers and locks that exist in the system. The SYSTEM LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 215

SECTION II

FUNCTIONAL REQUIREMENTS

OPERATOR shall be able to enter the system code, which is a unique identifier, and also the number of authorizations that will be available for assignment. Custom encoding If the Onity System Options have been configured, and if a magnetic card format is being used, the SYSTEM OPERATOR shall be able to configure the custom encoding of the magnetic card format. The Onity lock data shall be encoded on track 3 of a magnetic card if configured. A Fargo HDP5000 printer equipped with an ISO magnetic encoder and using driver version 2.0.0.5 or later shall support printing encoded badges. Magicard Rio2e/Tango2e printers equipped with an ISO magnetic encoder shall support printing encoded badges. Additionally, a Unitech MSR-206 stand alone encoder also supports track three magnetic encoding. The SYSTEM shall support configuring the Onity badge types so that they allow the SYSTEM OPERATOR to encode authorizations to badge types that get assigned to cardholders. Lock templates The SYSTEM shall provide support for Onity Integra lock templates. The SYSTEM shall support the ability to define resident and visitor templates. The template definition shall support the following configuration parameters: Template name Template type (either resident or visitor) Authorization assignment to the template Access levels Set / clear the override blocking flag for the template Assignment of a single Onity foyer lock level The SYSTEM shall support the ability to assign a Cardholder to a resident template or a Visitor to a Visitor template. Once a person is assigned to a template a credential can be encoded and issued that contains access information needed to gain entry to one or more locks. A template can be occupied by at most one person. The SYSTEM shall support the following functions related to template check-in: The ability to specify cardholder information at the time of check-in The ability to search for an existing cardholder and assign it to the template The ability to change the authorizations that were originally assigned to the template

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 216

SECTION II

FUNCTIONAL REQUIREMENTS

The ability to change the foyer lock level that was originally assigned to the template The ability to encode a card at the time of check-in Users shall not have the ability to change the override blocking flag that was originally assigned to the template. The badge template configuration shall support the ability to remove the current cardholder assigned to the template. When this operation is performed the badge template shall be re-assigned to the <UNASSIGNED> system cardholder. The concept of a personalized locking plan is one where a person may have most of the general access rights assigned via a badge template but also need some additional access rights specific to that person. The SYSTEM shall support issuing a new badge for a cardholder that is currently assigned to a badge template. This function serves the following purposes: 1) To replace a card for an existing cardholder/visitor template assignment if the card is lost or stolen 2) Supports the ability to modify the badge related data for a cardholder/visitor template assignment The SYSTEM shall support the ability to check-out (un-assign) multiple templates in a single operation. Users shall be able to select/search for a group of templates currently checked into people in the system and do a check-out for all. The SYSTEM shall support automatically managing personalized locking plan expirations. The SYSTEM shall support the ability to check the personalized access level assignments for each assigned template and remove access automatically for these doors if the access level expiration date has been reached. Badge template reporting The SYSTEM shall support badge template reporting. The SYSTEM shall be able to generate the following reports related to badge templates: report of all assigned templates in the system including who they are assigned to report of all unassigned templates in the system report of users assigned to a template

The SYSTEM shall support add/remove/modify a lock from System Administration. The SYSTEM shall support add/remove/modify an access level. The SYSTEM shall support add/remove/modify a time zone. The SYSTEM shall support add/remove/modify a

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 217

SECTION II

FUNCTIONAL REQUIREMENTS

cardholder. The SYSTEM shall support add/remove/modify a reader TZ list. The SYSTEM shall support add/remove/modify a holiday. Time zones The SYSTEM shall support using the SYSTEMs Time zones form to create time zones, each consisting of up to 6 time range/day intervals. The selectable days shall include any of the seven days of the week, plus any of up to 8 holiday types. The SYSTEM shall support configuring Onity cardholder authorization assignments so that the SYSTEM OPERATOR can customize a cardholders accessibility to locks and limit their access to areas without needing to update the locks. In the SYSTEMs Alarm Monitoring application, the SYSTEM OPERATOR shall be able to assign authorizations to a cardholders badge ID. The SYSTEM OPERATOR shall be able to assign specific authorizations to a cardholder, or assign all authorizations, or unassign all authorizations to a cardholders badge ID. The SYSTEM OPERATOR shall also be able to search for cardholder badge IDs based on search criteria and selected authorizations. The SYSTEM OPERATOR shall be able to select from the following search criteria: Does not have any of the selected levels, Has all and only the selected levels, Has all of the selected levels, and Has at least one of the selected levels. Based on the search criteria selected shall determine which cardholder badge ID(s) are then displayed. The SYSTEM shall support allowing users to operate WAP and Locks by Alarm Monitoring. The SYSTEM shall support changing the access mode from Alarm Monitoring, opening the door from Alarm Monitoring, downloading data, downloading WAP firmware, and downloading lock firmware. Blocking The SYSTEM shall support blocking cards for Onity Integra Locks. Blocking cards are used by authorized personnel to time access through doors; a single blocking card can be used to block access to any number of locks. Blocking cards shall be able to be set up and printed in the SYSTEM's System Administration application. The SYSTEM shall support override blocking setting for Onity badge records. This option shall give the user the ability to unlock a door that has been blocked with a blocking card. There shall be an override blocking checkbox on the Badge tab of the Cardholders form to support this. Blocking override setting is only stored in the lock, it is not on the card. XPP operator The SYSTEM shall support allowing the XPP operator to program a lock when it is first installed. The SYSTEM shall support enabling the XPP operator to update lock data with the data loaded into the XPP from the computer. The SYSTEM shall support allowing the XPP operator to retrieve lock audit data from the locks.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 218

SECTION II

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support allowing the XPP operator to change the date and time within the XPP. This function shall be used to change lock time for troubleshooting or to enter a time controlled mode of operation within the lock. The SYSTEM shall support allowing the XPP operator to view the lock audit data on the XPP display. This shall not affect the ability to view the lock audit data when it has been retrieved from the XPP by the computer. The SYSTEM shall support allowing the SYSTEM OPERATOR to change the mode of the lock. This function shall be used following initialization and testing to place the lock into the desired operating mode immediately, rather than waiting for the changes to occur on a schedule. The SYSTEM shall support automatically retrieving the lock audit data from the locks. The XPP shall automatically read openings during its Update function. If this is not enabled, the SYSTEM OPERATOR shall still be able to read openings from the locks by selecting the Read Openings function on the XPPs main menu. The SYSTEM shall support allowing the XPP operator to unlock a lock if that doors information has been loaded into the XPP. This shall even open a lock if the batteries are dead. The SYSTEM shall support allowing the XPP operator to unlock any door on the site, even if the batteries are dead. The SYSTEM shall support multiple Operators for Onity Integra Controllers. The Operator form shall allow the System Operator to add and configure passwords and permissions for up to sixteen (16) XPP operators to the Onity Integra access panel (controller). Lock modes The SYSTEM OPERATOR shall be able to select from the following Onity lock modes: Office, Office First, Standard, Blocked, Privacy, AFC, Security Passage, and Security. Office mode The lock shall be able to operate in Office mode. The lock shall be able to enter and exit Office mode depending upon the automatic changes and the user privileges. When the lock is in Office mode it shall allow free access i.e. it remains unlocked. The lock shall be able to be put into or taken out of Office mode by: presenting a valid token of a lock owner twice within 6 seconds automatically depending upon the automatic changes. The automatic changes for configuring the lock into Office mode only takes place when the lock is in the Standard mode. Office First mode The lock shall be able to operate in Office First mode. The lock shall be able to enter and exit Office First mode depending upon the automatic changes and the user privileges. When the lock is in Office First mode it allows free access i.e. it remains unlocked. The lock can be put into or taken out of Office First mode by: the first valid token of the day may be presented twice within 6 seconds automatically depending upon the automatic LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 219

SECTION II

FUNCTIONAL REQUIREMENTS

changes. The automatic changes for configuring the lock into Office First mode only takes place when the lock is in the Standard mode. Standard mode The lock shall be able to operate in the Standard mode. The lock shall be able to enter and exit Standard mode depending upon the user privileges. Blocked mode The lock shall be able to operate in Blocked mode. The lock shall be able to enter and exit the Blocked mode depending upon the user privileges. When the lock is in the Blocked mode it remains locked for all users except those that have blocking override privileges. The lock can be put into or taken out of Blocking mode by presenting a valid token of a blocking card. The lock can be configured into Blocked mode only when the lock is in the Standard mode or Office mode. After exiting the Blocking mode the lock enters the Standard operating state. Privacy mode The lock shall be able to operate in the Privacy state. The lock shall be able to enter and exit Privacy mode depending upon the user privileges. The firmware shall allow the lock to be put in Privacy state if the privacy knob is turned by the user. The lock cannot be put into this mode by Automatic Changes Tables. The firmware shall allow user with owner attribute to override the Privacy state. The firmware shall check to see that all user attributes along with the activation and expiration times are valid for that specific time and if matched will unlock the door. The users without owner attribute shall not be able to unlock the door. If the lock is in Privacy, and the owner of the lock inserts the card twice, then the lock shall go into Office mode with privacy enabled. The AFC type shall act in a similar manner to the sequential mode of lock except that the door relocking is not automatically taken care of in the software. In AFC, only the Standard and Security modes shall apply. The requirements for relocking of the door after the user enter / exits the room shall be: the software shall not automatically lock the door after the user enter / exits the room, the software shall not automatically lock the door after the user exits the room, the user shall have to use the valid card in order to lock the door, the software shall not automatically lock the door after the user enters the room, the user shall have to engage the privacy knob in order to lock the door, and if the privacy knob is not engaged the door shall remain unlocked. If the door is unlocked the software shall lock the door after a pre-defined time. This feature shall be enabled / disabled through the PP. The time shall be user-definable from 1 30 minutes. Security Passage mode Security Passage lock mode shall be a variant of Security mode that allows more flexible operation. The user must use a valid card and enter a valid four digit PIN to open the door. Use of a card with the Owner attribute may allow the lock to change to office mode LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 220

SECTION II

FUNCTIONAL REQUIREMENTS

(if enabled). If the valid card is inserted and removed in the lock (in case of MAG) or presented (in case of prox cards) with correct User PIN, the lock shall open and the LEDs shall glow. An audit shall be recorded. The card is inserted and removed before entering the PIN. The PIN should be entered within 6 Seconds. If the lock is already in Office mode and if the valid card is inserted and removed in the lock with correct user PIN, the lock shall enter into Security Passage mode again. If the lock is configured to lock the door as soon as the handle is released the lock shall lock the door. Security mode The Security lock mode shall be the highest security mode of the lock. Each user shall use a valid card and enter a valid four digit PIN to open the door. Cards with the owner attribute shall not be able to change the lock state to office mode. If the valid card is inserted and removed in the lock (in case of MAG) or presented (in case of prox cards) with the correct User PIN, the lock shall unlock the door and the LEDs shall glow. An audit shall be recorded. The card is inserted and removed before entering the PIN. The PIN should be entered within 6 Seconds. If the lock is configured to lock the door, as soon as the handle is released, the lock shall lock the door. Audit trail The lock shall maintain an audit trail in its memory. The software shall match the system code received from the PP with the system code in the lock. If the system code does not match, the software shall send an error message to the PP. An audit for the same shall be recorded. The software shall stop any further communication with the PP until the system code is validated. The lock shall record 1500 audit events at any time. The lock shall record the following events: Openings Events, Lock Events, Alarm Cancellation Events, Card Rejection Events, Automatic lock state change Events, Maintenance Events, and Lock malfunction. Lock Malfunction shall constitute events like, Reset (due to power interruption or circuit problem), Impossible opening records (memory errors), etc. The lock shall record the following data for each event: Date, Hour, Minute, Seconds, User code (for a user operation) / PP operator ID (for a PP operation), User sequence (for a user operation), and Event type. Codes The following shall be the various codes assigned to the Event type that the Lock will record: Opening Events: 1) Granted Access, 2) Granted Access (Card + PIN), 3) Granted Access only by user PIN, 4) Authorized access by common keyboard, 5) Access authorized by local button (EXIT), 8) Emergency Opening with PP or Adapter (A direct cable connection from PC to Lock)

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 221

SECTION II

FUNCTIONAL REQUIREMENTS

Lock Events: 9) Door was Opened from the interior, 10) Mechanical Key Override was used, 11) Deadbolt Projected from the Exterior, 12) Deadbolt Projected from the Interior, 13) Deadbolt withdrawn from the Interior. Warnings of Incorrect users: 14) Warning for door not opened after authorized access Alarms of Door Control: 16) alarm for Door Left Open, 18) Alarm for Intrusion, 19) Quiet alarm or duress (there is previous access), 20) Alarm for tamper Alarm Cancellation Events: 23) Door Closed, 24) Exterior hand activated being the door closed, 25) End of tamper, 26) Failure of clutch Causes of Card Rejection Events: 28) Card Format Error, 29) Card Not Active yet, 30) Expired Card, 31) Not Valid PIN, 32) Rejection by invalid common keypad (in Keypad mode), 33) User not Enabled, 34) Required Authorization Missing, 35) Rejection by cancelled card (old NSEQ),36) Rejection for card not being activated, 37) Rejection by outside hour, 38) No Privacy Override, 39) No Blocking Override, 42) Clock Stopped, 43) Rejection by very low batteries, 44) Undetermined Reason. State Changes Events: 45) Security Mode (Card + Keyboard), 46) Standard Mode (Card Only), 47) Keyboard Only, 48) Office First Mode, 49) Office Mode, 50 End of Office Mode, 51) Blocked, 52) End of Blocked, 53) Security Passage Mode (card + keyboard) AFC Events: 54) AFC Mode, 55) End of AFC Mode. Note: Audit log for End of Office mode and End of Blocked mode will have to be registered only when the event takes place with the help of valid user card. Also there shall be two audits recorded i.e. one will be End of Office/Blocked mode and the other would be Entered Standard mode. Technical Problems: 59) Reset of the circuit during the motor assets, 60) Loss of clock, 61) Low batteries, Maintenance Events: 66) DST (Daylight Savings Time), 67) Update of lock, 68) Collection of openings, 69) Test manual, 70) Card of diagnosis, 71) Initialization of the lock by PP, 72) Reset the circuit Lock Malfunction Event: 91) Rejection by malfunctioning of TARJ Switch

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 222

SECTION II 13.System Administration

a) System Configuration

FUNCTIONAL REQUIREMENTS

The SYSTEM shall provide system icons and/or menu selections for each function requiring configuration of SYSTEM options or peripherals (client workstations, field hardware, network functions, communications, reports, etc.). Icon tools bars shall be sizable, movable, and removable. Each form must be in a tab format and shall provide point and click mouse functionality using icons or drop down menus to insure configuration is simple. As soon as a function is defined, it shall appear in any other configuration form list that requires that function. The SYSTEM shall support sorting capabilities for multi-column lists. To sort on a multi-column list, the System Operator shall only have to click on the column that is to be sorted. These forms shall be available only to the System Administrator to make system additions or changes to existing configurations. All SYSTEM configuration options and forms shall be documented in the System Administrators Manual to assist in the selection of options. b) Pre-defined Database System Administrators shall have the option to install a pre-defined database onto their system complete with sample records and configurations. This sample database shall have a configuration that matches that of the VAR demo cases so that VARs can test and troubleshoot the SYSTEM if necessary. c) System Configuration Setup Wizards The SYSTEM shall support SYSTEM configuration setup wizards to guide System Administrators through the configuration of the access control module of the system. The setup wizards shall guide System Administrators step by step by asking a series of questions that, when answered, will allow the SYSTEM to automatically configure itself. The setup wizards shall allow for multiple devices to be added in a single command to allow for easy and efficient SYSTEM software setup. There shall be at minimum, setup wizards for Intelligent System Controllers and Card Readers. i) Multiple Language Support The SYSTEM shall support Unicode. The SYSTEM shall be available in a minimum of ten (10) languages including English, Arabic, Chinese, French, German, Hebrew, Italian, Korean, Russian, Spanish, and Swedish. The SYSTEM shall allow multiple languages to be installed on the same client workstation. System Operator login shall determine which language the graphical user interface shall display.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 223

SECTION II
j) Single Sign-on Support

FUNCTIONAL REQUIREMENTS

The SYSTEM shall provide support for single sign on capability. Single sign-on shall allow System Administrators/System Operators to authenticate into SYSTEM applications using their Windows domain account. Sign sign-on shall support the following scenarios: 1. Allow System Administrators/System Operators to interactively run SYSTEM applications without having to enter a username or password. This shall make administration of the SYSTEM easier since maintenance of separate SYSTEM usernames and passwords is not required. 2. Allow SYSTEM API scripts to authenticate. These scripts shall be run using a Windows account allowing a seamless and secure way to authenticate the account and restricting the script to those actions that the user is permitted to perform. k) Password Privileges The SYSTEM shall allow the System Administrator to configure each client workstation with those applications that may be run on that client workstation. Individual System Operator passwords will further restrict System Operator functions and shall be specific to each System Operator. Specific System Operator restrictions shall include: 1. Access to screens or functions (e.g.: alarm monitoring, badge issue) 2. Specific tasks allowed (e.g.: modify data, view only) 3. Alarm Monitoring functions (e.g.: clear alarms, output control, traces, reports) If a System Operator is denied access to specific functions, those functions shall not appear (or shall be ghosted) on the System Operators client workstation or menu bar while that password is logged in. Passwords shall not print in any report. System Administrators and Operators shall have the ability to change their password at any time in the SYSTEM by logging into the SYSTEM with their current password and then changing it through menu options. g) Strong Passwords The SYSTEM shall support the use of strong passwords. h) System Operators The SYSTEM shall support an unlimited number of System Operators at any time. Each System Operator shall be assigned a logon ID and password. Each System Operator shall be assigned permission levels for system administration & configuration functions, Credential Management functions, alarm monitoring functions, digital video management

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 224

SECTION II

FUNCTIONAL REQUIREMENTS

functions, asset management functions, visitor management functions, remote access level management functions, and database field viewing options. The SYTEM shall be able to provide information on the date and time a new System Operator was created. The SYSTEM shall also be able to provide information on the date and time the System Operator information was last modified. There shall also be a notes field when entering a new System Operator where information in regards to the System Operator can be stored. i) System Permissions Every major feature, function, and cardholder page in the SYSTEM shall be permission protected. Each System Operator shall be assigned permission or no permission to use/view/access each feature and function in the SYSTEM. Permission groups shall be broken into three categories: System Administration, Credential Management, and Alarm Monitoring. Every page in the Cardholder Form shall be permission protected. Each System Operator shall be assigned view permissions for each page of information in the Cardholder Form. Every database field in the SYSTEM shall be permission protected. Each System Operator shall be assigned view/edit permissions for each personnel database field in the SYSTEM. j) Network Account Management The SYSTEM shall support a Network Account Management module. The SYSTEMs Network Account Management Module shall integrate SYSTEM cardholders with external user network accounts. Through linked accounts, System Administrators shall be able to perform a set of administrative tasks in Windows domains from the System Administration Module. The Network Account Management functionality shall also enable System Administrators to create a link between physical access control and logical domains. The SYSTEM shall additionally be combined with the management of cardholders digital certificates stored on a smart card. The integration shall provide a number of benefits, including the ability to do the following:
1.

Perform administrative functions on Windows user accounts from within the SYSTEM Administration Module. Enable interaction between Physical Access Control Cardholders and Windows logical domains. For example, if badge is lost, a designated Windows account shall disable. Control access to Computer Anti-Passback Areas Issue Windows 2008/2003 Smart Card Logon and Smart Card User certificates on the user's smart card. LENEL - A UTC FIRE & SECURITY COMPANY

2.

3. 4.

OnGuard

Functional Specifications Version 6.3 Series

Page 225

SECTION II
1) Adding a New Account

FUNCTIONAL REQUIREMENTS

During creation of cardholder records, System Operators shall select an option to create a network account for a new cardholder. The selected network account type shall determine the Windows 2008/2003 domain and a set of permissions for the new account. 2) Lost Badge If a cardholder loses their badge, the System Operator shall change the reported badge status from Active to Lost. When the badge status is changed, all of the cardholders linked network accounts automatically shall disabled. 3) Computer Anti-Passback Area Access

Customer has set a security policy, which only allows access to computers in designated areas to personnel physically present in these areas. An employee must present a badge to the card reader in order to enter and exit these secure areas. A cardholder has access levels that allow him to enter secure area A. In addition, he has a network account of type B, which allows him access to computers in area A. When the cardholder gets access granted on entry reader of area A, his computer account of type B is enabled. When the cardholder leaves the area his network account becomes disabled. k) System Operator Activity Logging The SYSTEM shall provide full System Operator activity tracking of critical keyboard functions. The activity log shall be comprehensive, recording the date and time of the activity, the client workstation at which the activity was performed, the System Operator who performed the activity, the program the activity occurred in, and the function that was performed within it. The SYSTEM shall record any and all changes to the database made by all System Operators. The SYSTEM shall log all System Operator functions, including System Operator Log-in and System Operator Log-out; Additions, Changes, and Deletions to Cardholder Management; New Badge, Print Badge, and Update Badge; and other critical database functions. The SYSTEM shall log changes made to the access control configurations: Changes of access levels, holidays, time zone changes, card readers, and other critical items. The SYSTEM shall log changes made to the digital video configurations including changes to digital video recorders, cameras, device links, and other critical functions. The SYSTEM shall log changes made to the asset management configurations including changes to asset readers, assets, asset assignments and other critical functions.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 226

SECTION II

FUNCTIONAL REQUIREMENTS

The SYSTEM shall log changes to the visitor management configurations including the enrollment of visitors, assignment of visitors to cardholders, scheduling visits, and other critical functions. The SYSTEM shall log changes to the intrusion detection management configurations including the configuration of areas and zones, arming/disarming areas, and other critical functions. The SYSTEM shall log activity of System Operators performing SYSTEM alarm monitoring; i.e. alarms acknowledged, cleared, output control activity, trace, and other functions. The SYSTEM shall permit the System Administrator to define the number of days worth of activity to keep on-line before the System Administrator purges the oldest data off-line. The activity log will have a field to show the number of total System Operator events that are currently stored in the database. The number of events to keep on-line shall only be limited by the amount of disk space available on the database server. The SYSTEM shall provide a System Operator activity report to query the above information available in the SYSTEM database. Client workstation, System Operator, date and time, or other selection criteria shall sort the report. On those occasions when historical data shall be needed, the System Operator activity report shall be generated from an archived database as well as from the active SYSTEM database. l) Alarm/Event Activity Logging The SYSTEM shall provide full access/alarm/event activity logging. The activity log shall provide comprehensive logging of date and time of the transaction, where the transaction occurred, acknowledgment information, and any System Operator actions. The SYSTEM shall log all access grants, access denies, alarm actives, asset denies, and other critical and non-critical alarms. The SYSTEM shall give System Administrators the ability to choose when to log certain types of alarms. The log shall be broken down into the following categories: Events and Alarm Acknowledgements, User Transactions, and Visits. For each type of alarm, the System Administrator can set how long to keep each group of events. For example, visits may only be kept in the history file for 7 days while User Transactions may be kept for one year. The activity log will have a field to show the number of total events that are currently stored in the database. The number of events to keep on-line shall only be limited by the amount of disk space available on the database server. The SYSTEM shall log a minimum of 1,000,000 events before the System Administrator purges the oldest data to an off-line file. The hard drive space required to store 1,000,000 events shall not exceed 40 MB.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 227

SECTION II

FUNCTIONAL REQUIREMENTS

The SYSTEM shall provide activity reports to query the above information available in the SYSTEM database. The reports shall be sorted by client workstation, alarm type, date and time, or other selection criteria. On those occasions when historical data shall be needed, the activity reports shall be generated from an archived database as well as from the active SYSTEM database. m) Encryption of PIN Codes inside the Database Server The SYSTEM shall encrypt all cardholder PIN codes such that no one, including the Systems Administrator, shall have access to cardholder PIN codes through the application or through the database server. n) Access Control Reports There shall be a minimum of one hundred twenty-five (125) standard SYSTEM reports provided with the SYSTEM. All reports MUST be stored in the SYSTEM database and MUST be able to be viewed from any SYSTEM client workstation with proper permissions. Reports shall use UTC time. The SYSTEM shall allow the SYSTEM USER to e-mail reports based on system events or on a user defined schedule. The standard reports that shall be included with the SYSTEM are described below: 1) Access Denials and Grants by Reader Report The Access Denials and Grants by Reader Report shall provide information on all access denials and granted events including time, card reader, badge, and cardholder name, sorted by card reader. 2) Access Denials, Grants, and Other Badge Events Report The Access Denials, Grants, and Other Badge Events report shall provide information on all badge related events including time, reader, badge, and cardholder name. 3) Access Denied Event Report The Access Denied Event Report shall provide information on all access denied events including time, card reader, badge, and cardholder name. 4) Access Denied Event by Reader The Access Denied Event by Reader Report shall provide information on all access denied events including time, card reader, badge, and cardholder name, sorted by card reader. 5) Access Granted Events Report The Access Granted Events Report shall provide information on all access granted events including time, card reader, badge, and cardholder name.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 228

SECTION II

FUNCTIONAL REQUIREMENTS
6) Access Granted Events by Reader Report The Access Granted Events by Reader Report shall provide information on all access granted events including time, card reader, badge, and cardholder name, sorted by card reader. 7) Access Groups Report The Access Groups Report shall provide information on all access groups and the access levels contained in each group. 8) Access Groups with Levels Report The Access Groups with Levels Report shall provide information on all access group definitions including access level details. 9) Access Level Assignments to Cardholders Report The Access Level Assignments to Cardholders Report shall list each access level with a listing of each cardholder that has that access level assigned to them. 10) Access Levels Assignment to Cardholders, By Segment Report The Access Levels Assignment to Cardholders, By Segment Report shall provide information on all cardholders with access levels, sorted by segment. Only personnel with assigned access levels shall be included in the report. This report shall also summarize the total number of badges that will need to be downloaded to each segment. This report only shall only work on a system utilizing database segmentation. 11) Access Levels Report The Access Levels Report shall provide information on all access level definitions. 12) Access Panels Report The Access Panels Report shall provide information on all access panel definitions. 13) Active Visits by Cardholder Name Report The Active Visits by Cardholder Name Report shall provide information on all visits that are currently active (not signed out) grouped by cardholder name. 14) Active Visits by Visitor Name Report The Active Visits by Visitor Name Report shall provide information on all visits that are currently active (not signed out) grouped by Visitor Name.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 229

SECTION II
15) Alarm Acknowledgments Report

FUNCTIONAL REQUIREMENTS

The Alarm Acknowledgments Report shall provide information on all alarm acknowledgments including the alarm information and acknowledgment notes. 16) Alarm Acknowledgements by Definition Report The Alarm Acknowledgments by Definition Report shall provide information on all alarm acknowledgments including the alarm information and acknowledgment notes, sorted by Definition. 17) Alarm Acknowledgments by System Operator Report The Alarm Acknowledgments by System Operator Report shall provide information on all alarm acknowledgments including the alarm information and acknowledgment notes, sorted by System Operator. 18) Alarm Acknowledgements by Panel Report The Alarm Acknowledgments by Panel Report shall provide information on all alarm acknowledgments including the alarm information and acknowledgment notes, sorted by Intelligent System Controller Panel. 19) Alarm Configuration Report The Alarm Configuration Report shall provide alarm configuration summary information. 20) Alarm Input Events Report The Alarm Input Events Report shall provide information on all alarm input events sorted by date. 21) Alarm Panel Inputs Report The Alarm Panel Inputs Report shall provide information on all alarm panel inputs grouped by access panel and alarm panel. 22) Alarm Panel Local Linkage Report The Alarm Panel Local Linkage Report shall provide information of all input and output linkages within an ICM. 23) Alarm Panel Outputs Report The Alarm Panel Outputs Report shall provide information on all alarm panel outputs grouped by access panel and alarm panel. 24) Alarm Panels Report The Alarm Panels Report shall provide information on all alarm panel definitions grouped by access panel.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 230

SECTION II
25) All Events Over Time Report

FUNCTIONAL REQUIREMENTS

The All Events Over Time Report shall provide a listing of all event types over time. 26) All Events Over Time with Unique Alarm ID Report The All Events Over Time with Unique Alarm ID Report shall provide a listing of all event types with an unique alarm ID over time. 27) Anti-Passback Events Report The Anti-Passback Events Report shall provide a listing of all anti-passback events over time 28) Area Anti-Passback Configuration Report The Area Anti-Passback Configuration Report shall provide a listing of all antipassback areas, including the reader entrances and exits. 29) Area Entrance History Report The Area Entrance History Report shall provide a history of all cardholders enter anti-passback areas, sorted by area and date. 29) Asset Classes Report The Asset Classes Report shall provide information on all asset classes and the asset groups to which they belong. 30) Asset Events Report The Asset Events Reports shall provide information on all asset events. 31) Asset Groups Report The Asset Groups Report shall provide information on all asset groups and the classes they contain. 32) Asset Types Report The Asset Types Report shall provide information on all asset types defined with all associated subtypes. 33) Assets by Scan ID Report The Assets by Scan ID Report shall provide information on all assets grouped by Scan ID. 34) Assets by Type Report The Assets by Type Report shall provide information on all assets grouped by asset type and subtype.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 231

SECTION II

FUNCTIONAL REQUIREMENTS
35) Assigned Assets by Cardholder Report The Assigned Assets by Cardholder Report shall provide information on all currently assigned assets grouped by cardholder. 36) Assigned Assets by Scan ID Report The Assigned Assets by Scan ID Report shall provide information on all currently assigned assets grouped by Scan ID. 37) Assigned Assets by Type, Scan ID Report The Assigned Assets by Type, Scan ID Report shall provide information on all currently assigned assets grouped by type and Scan ID. 38) Audio Notifications and Instructions Report The Audio Notifications and Instructions Report shall list all audio notifications and instructions in the database. 39) Badge Type Configuration The Badge Type Report shall provide a listing of all Badge Types. 40) Badges by Deactivation Date Report The Badges by Deactivation Date Report shall list all badges by deactivation date. Shall be used to determine which badges are about to deactivate. 41) Badges Without Access Levels Report The Badges Without Access Levels Report shall provide information on all Badges that do not have any access levels assigned to them. Badges with access levels assigned to them shall not be listed in this report. 42) Card Formats Report The Card Formats Reports shall provide information on definitions of all Magnetic and Wiegand card formats in the SYSTEM. 43) Cardholders Access to Readers Report The Cardholders Access to Readers Report shall provide a listing of each card reader along with which cardholders have access to that card reader. Includes associated access level and time zone. 44) Cardholder Exit/Entry Report The Cardholder Exit/Entry Report shall provide information on all user-defined Exit/Entry information on a per cardholder basis. It shall list the time a cardholder swipes their badge at a designated In reader and the time they swiped their badge at the corresponding designated Exit reader.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 232

SECTION II

FUNCTIONAL REQUIREMENTS
45) Cardholder Guest Access to Readers Report The Cardholder Guest Access to Readers Report shall provide a listing of each card reader and the cardholders that have access to it via Guest badge assignment. 46) Cardholder Photo Gallery Report The Cardholder Photo Gallery Report shall provide cardholder names and photos, sorted by last name. 47) Cardholder Time and Attendance Report The Cardholder Time and Attendance Report shall pair each in-time with an outtime for cardholders gaining entry to time and attendance readers. 48) Cardholders by Badge Type Report The Cardholders by Badge Type Report shall provide information on all cardholders sorted by badge type. No access levels are shown in this report and cardholders that have not been assigned a badge type will not be reported. 49) Cardholders by Last Name Report The Cardholders by Last Name Report shall provide information on all cardholders sorted by last name, with badges but not access levels. Only personnel with badges assigned shall be included in this report. 50) Cardholders Located in Each APB Area by Date Report The Cardholders Located in Each APB Area by Date Report shall provide a list of all cardholders located in each anti-passback area, sorted by area and date. 51) Cardholders Located in Each APB Area by Name Report The Cardholders Located in Each APB Area by Name Report shall provide a list of all cardholders located in each anti-passback area, sorted by area and cardholder name. 52) Cardholders with Access Levels by Badge Type Report The Cardholders with Access Levels by Badge Type Report shall provide information on all cardholders with access levels, sorted by badge type. Only personnel with active badges and assigned access levels will be included with this report. 53) Cardholders with Access Levels by Last Name Report The Cardholders with Access Levels by Last Name Report shall provide information on all cardholders with access levels, sorted by last name. Only personnel with active badges and access levels shall be included in this report.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 233

SECTION II
54) CCTV Instructions Report

FUNCTIONAL REQUIREMENTS

The CCTV Instructions Report shall provide summary information on all CCTV instructions in the database. 55) Cisco AIC Inputs Report The Cisco AIC Inputs Report shall provide information on all Cisco AIC inputs configured in the SYSTEM. 56) Cisco AIC Outputs Report The Cisco AIC Outputs Report shall provide information on all Cisco AIC outputs configured in the SYSTEM. 57) Continuous Video Report The Continuous Video Report shall provide a listing of all of the times continuous video is archived. 58) Current Visits Report The Current Visits Report shall provide a list of all currently signed in visits. 59) Destination Assurance Configuration Report The Destination Assurance Configuration Report shall provide a listing of all card readers configured for Destination Assurance with their associated lead times to proceed to the next defined card reader. 60) Destination Assurance Exempt Cardholders Report The Destination Assurance Exempt Cardholders Report shall provide a listing of all cardholders who are exempt from following Destination Assurance procedures. 61) Device Status Events Report The Device Status Events Report shall provide information on all status events for all devices in the SYSTEM. 62) Dial Up Events by Panel Report The Dial Up Events by Panel Report shall provide information on all dial up related events grouped by Intelligent System Controller. 63) Dial Up Last Connect Time Report The Dial Up Last Connect Time Report shall provide a list of all on-line dial up panels and the last time that they were connected to the SYSTEM database server.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 234

SECTION II

FUNCTIONAL REQUIREMENTS
64) Elevator Access Denials and Grants Report The Elevator Access Denials and Grants Report shall provide information on all elevator related access denied and granted events including floor selected, time, card reader, badge, and cardholder name. 65) Emergency Events Report The Emergency Events Report shall provide a listing of all emergency events over time. 66) Event Codes Report The Event Codes Report shall provide information on all event code templates and event code mapping configurations. 67) Event Count by Panel Report The Event Count by Panel Report shall provide a count of all events grouped by Intelligent System Controller. This report shall include a pie chart breakdown. 68) Fire Device Input/Output Report The Fire Device Input/Output Report shall provide a listing of all fire inputs and outputs grouped by panel and fire device. 69) Global APB/MobileVerify Occupancy by Date Report The Global APB/Mobile Verify Occupancy by Date Report shows the last known area accessed by each cardholder, sorted by date and time. 70) Global APB/MobileVerify Occupancy by Name Report The Global APB/Mobile Verify Occupancy by Name Report shows the last known area accessed by each cardholder, sorted by cardholder. 71) Global I/O Linkages Report The Global I/O Linkages Report shall provide a listing of all global I/O linkages, including the input events and output actions. 72) Guard Tour Configuration Report The Guard Tour Configuration Report shall provide a listing of all configured guard tours, including checkpoints, actions, and messages. 73) Guard Tour History Report The Guard Tour History Report shall provide a listing of all events associated with checkpoints that happened for each guard tour.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 235

SECTION II
74) Hardware Panels Report

FUNCTIONAL REQUIREMENTS

The Hardware Panels Report shall provide information on all top level hardware panels grouped by category including access panels, fire panels, intercom panels, personal safety panels and central station alarm receivers. 75) Holidays Report The Holidays Report shall provide information on all system holiday definitions. 76) Intercom Functions Report The Intercom Functions Report shall provide information on all defined intercom functions. 77) Intercom Stations Report The Intercom Stations Report shall provide information on all intercom stations, grouped by intercom exchange. 78) Intrusion Detection Areas Report The Intrusion Detection Areas Report shall provide a listing of all intrusion areas grouped by panel. 79) Intrusion Detection Devices Report The Intrusion Detection Devices Report shall provide a listing of all intrusion devices grouped by panel. 80) Intrusion Panel User Groups Report The Intrusion Panel User Groups Report shall provide a listing of all intrusion user groups grouped by panel. 81) Last Location of Cardholders Report The Last Location of Cardholders Report shall provide information on the last card reader accessed by each cardholder, sorted by cardholder name. 82) Maps Report The Maps Report shall provide a list of all available maps in the database. 83) Mobile Verify User Transaction Log Report The Mobile Verify User Transaction Log Report shall provide a chronological log of all performed transactions. 84) Mobile Verify User Transaction Log by Operation Report The Mobile Verify User Transaction Log by Operation Report shall provide a chronological log of all performed transactions grouped by operation.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 236

SECTION II

FUNCTIONAL REQUIREMENTS
85) Mobile Verify User Transaction Log by User ID Report The Mobile Verify User Transaction Log by User ID Report shall provide a chronological log of all performed transactions grouped by User ID. 86) Monitor Stations Report The Monitor Stations Report shall provide information on all monitoring stations defined in the SYSTEM including which monitor zones and access panels are assigned to the monitoring station. 87) Monitor Zones Report The Monitor Zones Report shall provide information on all monitor zone definitions. 88) Overdue Visits Report The Overdue Visits Report shall provide a listing of all scheduled visits that have not signed in. 89) Overstayed Visits Report The Overstayed Visits Report shall provide a listing of all visitors logged into the facility, but whose badge or visit has expired. 90) Personal Safety Transmitter Assignments Report The Personal Safety Transmitter Assignments Report shall provide information on all personal safety transmitters and their assignments to cardholders and assets. 91) Personal Safety Transmitters Report The Personal Safety Transmitters Report shall provide information on all personal safety transmitters. 92) Personnel in the Database Report The Personnel in the database Report shall provide information on all personnel in the database with basic information. 93) Personnel Without an Active Badge Report The Personnel Without an Active Badge Report shall provide information on all personnel in the database that do not have an active badge assigned to them. 94) Personnel with Organizational Details Report The Personnel with Organizational Details Report shall provide information on all personnel in the database with organizational details. This report is designed to work with the SYSTEM standard cardholder layout.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 237

SECTION II

FUNCTIONAL REQUIREMENTS
95) Personnel with Personal Details Report The Personnel with Personal Details Report shall provide information on all personnel in the database with personal details. This report is designed to work with the SYSTEM standard cardholder layout. 96) Point of Sale Registers Report The Point of Sale Registers Report shall provide a listing of all Point of Sale Registers configured in the SYSTEM. 97) Precision Access Groups Report The Precision Access Groups Report shall provide information on all precision access group definitions. 98) Reader Assignment to Cardholders Report The Reader Assignment to Cardholders Report shall provide a listing of all card readers assigned to a cardholder, sorted by cardholder. 99) Reader Status Events Report The Reader Status Events Report shall provide information on card reader status events, grouped by card reader. 100) Reader Time Zone Schedules Report

The Reader Time Zone Schedules Report shall provide information on all card reader time zone scheduling for card reader modes. 101) Readers Report

The Readers Report shall provide information on all card reader definitions grouped by access panel. 102) Receiver Account Areas Report

The Receivers Account Areas Report shall provide a listing of all receiver account areas, grouped by receiver account. 103) Receiver Account Groups Report

The Receivers Account Groups Report shall provide a listing of all receiver account groups and the receiver accounts contained in each group. 104) Receiver Account Zones Report

The Receivers Account Zones Report shall provide a listing of all receiver account zones, grouped by receiver account.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 238

SECTION II
105) Receiver Accounts Report

FUNCTIONAL REQUIREMENTS

The Receiver Accounts Report shall provide a listing of all receiver accounts in the SYSTEM. 106) Receiver Accounts that Failed to Report Report

The Receiver Accounts that Failed to Report Report shall provide a listing of receiver accounts that failed to report during their duration. 107) Receiver and Receiver Account Events Report

The Receiver and Receiver Account Events Report shall provide a listing of all events that occurred on a receiver or receiver account. 108) Segment Badge Download Summary Report

The Segment Badge Download Summary Report shall provide information on each segment by listing the number of badges that must be downloaded to the access panels in that segment. This report shall only work on systems utilizing database segmentation. 109) Segments Report

The Segments Reports shall provide a listing of all segments defined in the SYSTEM along with their options. 110) SNMP Agents Report

The SNMP Agents Report shall provide a listing of all SNMP Agents configured in the SYSTEM. 111) SNMP Management Information Base Configuration

The SNMP Management Information Base Report shall list all MIB data grouped by enterprise. 112) Text Instructions Report

The Text Instructions Report shall provide information on all text instructions defined in the SYSTEM. 113) Time Zones Report

The Time Zones Report shall provide information on all time zone definitions. 114) User Permissions Report

The User Permissions Report shall provide information on all SYSTEM users and their permissions.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 239

SECTION II
115) User Transaction Log Report

FUNCTIONAL REQUIREMENTS

The User Transaction Log Report shall provide a chronological log of all transactions performed on the SYSTEM by users. 116) User Transaction Log by User ID Report

The User Transaction Log by User ID Report shall provide a chronological log of all transactions performed on the SYSTEM by users grouped by User ID. 117) Users with Area Access Levels to Manage Report

The Users with Area Access Levels to Manage Report shall list all Area Access Manager Users with the access levels that they manage. 118) Video Cameras Device Links Report

The Video Cameras Device Links Report shall provide information on all device links for each video camera. 119) Video Cameras Report

The Video Cameras Report shall provide information on all video cameras grouped by digital video recorder. 120) Video Events Report

The Video Events Report shall provide information on all SYSTEM events with associated video events. 121) Video Servers Report

The Video Servers Report shall provide information on all digital video recorders. 122) Visits History Report

The Visits History Report shall provide information on all visits enrolled into the SYSTEM. 123) Visitors Report

The Visitors Reports shall provide information on all visitors in the SYSTEM. 124) Windows Event Log Errors Report

The Windows Event Log Errors Report shall provide information on all errors logged by the SYSTEM to the Windows event log. The report user interface in System Administration shall allow the System Administrator to filter on the UTC time columns. The SYSTEM shall provide filters for each report that, depending on the report that the System Administrator is running, will allow the System Administrator to filter any of the LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 240

SECTION II

FUNCTIONAL REQUIREMENTS

below listed criteria. The SYSTEM shall allow reports to be filtered by any combination of card readers, date and time, cardholder first name and/or last name, area, Action Type, Details or Object, Alarm Acknowledgement and/or badge ID. The SYSTEM will store all reports in the database so that all client workstations will have instant access to the report. The reports shall not be installed in a shared disk directory. The SYSTEM shall support advanced filters. The SYSTEM shall allow reports to use the Time filter to span across multiple days to create shift reports. For example, a report shall be able to be run that shows all access grants that occurred Monday through Friday, but on during the hours of 8:00 AM to 5:00 PM on those days. The SYSTEM shall allow for cardholder related reports to be run from the Alarm Monitoring Module of the SYSTEM. When running a report, the SYSTEM shall alert the System Administrator if the report contains deprecated fields. The current World Time Zone shall display on a report when it is run, along with report date/time. The SYSTEM shall allow System Administrators to specify card readers as either an in reader or an out reader. The designation of these card readers will act as another filter to use in conjunction with the standard reports to produce raw data which shall be exported to external systems such as Human Resources or Excel Spreadsheets which can crunch the data for Time and Attendance purposes. The SYSTEM reporting interface shall be available from the System Administration Module as well as the Alarm Monitoring Module. The SYSTEM shall support configuring default printers for printing reports. o) On-Line Documentation The SYSTEM shall support an on-line documentation feature. Thus, all documentation must be available on the application disc to allow complete on-line viewing of system documentation. The SYSTEM must also allow for the option of installing the documentation onto individual PC client workstations so that System Operators will not need the application disc to view the on-line documentation. p) Ad-hoc Database Report Generator The SYSTEM must provide an ad-hoc customized report generator package integrated with the SYSTEMs database. This program shall allow the System Administrator to create reports using the relational database structure. Among other reports, a tabular type report shall be configurable which will detail any information from the database in a columnar format with headings, breaks, sub-totals and totals. The report must also be able to be created to produce a flat ASCII export file. Access rights shall be provided to allow LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 241

SECTION II

FUNCTIONAL REQUIREMENTS

the System Administrator the privilege of creating, deleting, updating, saving, processing, viewing and printing reports. The reports are to be printed on a dot matrix printer or on a laser printer. Report configuration shall use menu options and drop down list-boxes to define that database fields are to be used, linked, or joined. They shall also be used to specify conditions and column order, as well as describe the layout and headings. q) Custom Report Writer The SYSTEM shall support an industry standard, off the shelf, custom report writer, such as Crystal Reports XI (11.5) Release 2. The custom report writer shall support multiple report types including, but not limited to, multiple section reports, form style reports, conditional reports, query reports, and columnar reports. The custom report writer shall have BLOB Bitmap support and shall come standard with a formula editor with more than 160 built in functions for System Operators to manipulate data. It shall have export capabilities to ASCII files, Microsoft Mail, or ODBC file formats. The custom report writer shall be compatible with industry standard SQL databases, such as Microsoft SQL Server 2005 or Microsoft SQL Server 2008. r) System Tape Backup A mandatory requirement, the SYSTEM shall provide tape backup and restore programs utilizing the multi-tasking capabilities of the SYSTEM and operating system. These programs shall run concurrently with any other application. Database backup must occur dynamically while other alarm monitoring, badging, access control applications remain active. The tape backup feature shall allow for three levels of tape backup; 1) Incremental, which will backup to tape all changes to data and images that have changed since the last incremental tape backup, 2) System, which will backup the operating system and application files only, and 3) Full, which backups all files. A database snapshot shall occur prior to a tape backup and the actual backup shall be performed in the background, utilizing the benefits of the multi-tasking operating system, without interfering with the ability of System Operators to exercise other functions. s) Client workstations System Administrators shall have the ability to configure each client workstation on the SYSTEM to utilize any combination of event printers, CCTV controllers, and video capture boards. For each printer or CCTV controller, System Administrators shall be able to select the port that the device is connected to on the client workstation and the communications speed. t) PIN Numbers The SYSTEM shall have the ability to support up to nine (9) digit PIN Numbers for each cardholder in the SYSTEM. PIN Numbers shall be created either manually through System Operator entry or generated randomly by the SYSTEM. The SYSTEM shall have

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 242

SECTION II

FUNCTIONAL REQUIREMENTS

the ability to be configured to allow for unique PINs for each cardholder and the ability to modify cardholders PIN numbers at a later date. u) List Builder System Administrators shall have the ability to pre-define information that will appear in each of the pre-defined drop down lists. There shall be no limit to the number of items that shall be a part of a list. Lists can have items added to them or deleted from them at any time. v) Archiving The SYSTEM shall allow System Administrators to archive off-line history files to magnetic media. Off-line files shall include access events and System Operator transactions that have been purged from the reportable database. The off-line files MUST be in a ready to import format for easy insertion of information back into the on-line database. Different event types may remain in the database for different time periods according to the System Operators specification. Any record older than the specified dates shall be purged to the off-line history file for archiving. Reports shall be generated from the archived files if necessary. Archiving shall be a scheduled, automatic function. w) Remote Dial-In Capabilities The SYSTEM shall support remote dial-in capabilities for SYSTEM troubleshooting, SYSTEM configuration, and alarm monitoring capabilities. VAR and/or System Administrators shall be able to dial in to the CUSTOMER database server to troubleshoot the CUSTOMERs system. This will allow System Administrators to locate any problem areas and, many times, fix the error over the telephone from a remote location. Remote dial-in shall also be used for SYSTEM configuration and/or alarm monitoring from remote locations using a client workstation. The client workstation shall have the ability to operate on a Laptop PC that meets the client workstation minimum specifications.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 243

SECTION II 14. Mobile Enterprise Applications

FUNCTIONAL REQUIREMENTS

This section is designed to be utilized in addition to, and in conjunction with, the rest of the SYSTEM Functional Generic Specification. It is designed for use with those systems that deploy, or wish to deploy, the SYSTEM Mobile Enterprise Architecture for Mobile Computing requirements. The Mobile Enterprise Architecture is a mobile, synchronized database solution that is designed for customers with mobile computing needs. Mobile Enterprise functionality shall be a seamlessly integrated, robust solution that transports virtually all SYSTEM client functions to a wearable, portable computer that connects to the network and SYSTEM Server via 802.11B wireless Ethernet on-line, or as a standalone solution that can be synchronized with the SYSTEM Server on an operational basis. At a high level, Mobile Enterprise shall offer: Wearable computers for mobile computing applications Standard SYSTEM software Wireless network connectivity Standalone operations Central Database Storage Facilities Data Synchronization Between Multiple Databases Mobile Alarm Monitoring and System Administration Capabilities Unlimited Expansion Capabilities Open Architecture Design Advanced Network Design Integration with Digital Video, ID Credential Management, and Visitor Management Systems

The SYSTEM shall support a multi-PC, multiple database synchronization architecture (herein after Mobile Enterprise Architecture) using a database server. The database server shall allow multiple wearable/mobile computers to be connected to it (via wired or wireless LAN/WAN architecture). In a stand-alone environment, connections shall occur only during synchronization. The database server shall contain a master copy of all relevant system data. An unlimited number of mobile enterprise client workstations may be connected to the database server. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 244

SECTION II

FUNCTIONAL REQUIREMENTS

In a stand-alone environment the mobile enterprise computing PC shall contain a copy of all required core information obtained from the database server. This shall include, but not be limited to, cardholders, badges, badge types, and access permissions. At predetermined, user definable, periodic intervals, each of the stand-alone mobile enterprise computers shall connect to the database server to perform a database synchronization process. In a wireless, on-line environment during daily SYSTEM operation, each of the mobile enterprise client workstations shall be connected locally to the database server via industry standard 802.11b wireless network connectivity. Mobile enterprise client workstations shall be any combination of system administration, alarm monitoring, digital video, visitor management, remote access level management, or ID management applications. Unlimited system expansion and scalability shall be possible with the Mobile Enterprise architecture. There shall not be a limit to the number of mobile enterprise computing PCs that can be deployed. a) Application Support Mobile Enterprise shall support any SYSTEM application on its mobile computing platform including:
1. 2. 3. 4. 5. 6.

Access Control Alarm Monitoring ID Credential Management Digital Video Intrusion Detection Visitor Management

b) Platform Support Mobile Enterprise shall be deployed onto a mobile PC computing platform. Minimum mobile computing platform specifications shall be as follows: OS: Microsoft Windows 2008 or 2003 or XP or Vista Processor: 600 MHz Transmeta Crusoe Size: 9.75" (L) x 3" (W) x 1.25" (D) Weight: 22 oz RAM: 128 MB DRAM Hard Drive: 6 GB or greater LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 245

SECTION II
PC Card slots: Two Type II or one Type III Temp Range: 32F to 122F (0C to 50C) Battery: Lithium Ion, Hot-Swappable Run time: 7 to 12 hours on two battery system

FUNCTIONAL REQUIREMENTS

Display: SVGA Indoor/Outdoor glass with Magnesium case c) Mobile Verify Mobile Enterprise shall support a Mobile Verify software option specifically designed for Mobile Enterprise Solutions, which shall provide the ability for an officer to use an optional scanner or card reader to automatically search the database for access privileges. The officer shall instantly be presented with the answer of either Access Granted or Access Denied based on the credential holders privileges. This functionality shall be accomplished in either standalone or on-line mode. d) Network Connectivity Mobile Enterprise shall be deployed using industry standard 802.11b wireless network technology. With its high throughput and long range, 802.11b shall operate in the unlicensed 2.4-GHz frequency spectrum that is well established in corporate wireless markets. e) Stand-alone Mode Mobile Enterprise shall also be deployed as a stand-alone mode. In a stand-alone environment the mobile computing PC shall contain a copy of all required core information obtained from the database server in order to execute Mobile Verify functionality. This shall include, but not be limited to, cardholders, badges, badge types, and access permissions (see bullet C above). f) Login Privileges Any mobile enterprise client workstation shall have the ability to log into the system for the purpose of System Administration, Alarm Monitoring, ID Credential Management, Mobile Verify, etc. The System Administrator or System Operator at the mobile enterprise client workstation will have appropriate privileges based on their login ID and permissions for that particular user account as determined on the database server g) User Transactions User transactions shall be logged on all mobile enterprise computing clients and shall be stored at the database server.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 246

SECTION II Badge Layout Creation Module

FUNCTIONAL REQUIREMENTS

The SYSTEM shall provide a Badge Layout Creation and Editing Module to allow for the creation of custom badge designs to be created by the CUSTOMER. The SYSTEM shall support credit card, government, and custom credential sizes in either a landscape or portrait format. a) Badge Layout Objects The SYSTEM shall support multiple object types, all of which shall be placed on the layout in any order and combination. These objects shall include alphanumeric text fields, database fields, photos, signatures, logos, graphics, shapes (Square, circle, rectangle, ellipse), and bar-codes. Objects shall be placed onto the layouts through a Windows drag and drop process. b) Advanced Database Field Driven Badge Layouts The SYSTEM shall support advanced functionality that allows cardholder database information to control what information is printed onto a cardholders credential. Thus, a single generic layout shall be created, and attributes such as colors, borders, logos, typefaces, backgrounds, etc. shall be determined by the information of a particular database field. For example, when Marketing is entered in the Department field, a green background shall be printed on the badge. However, when Engineering is entered in the Department field, a blue background shall be printed on the badge. Any information displayed in a dropdown list shall have the ability to control any of the following credential attributes: The SYSTEM shall support insertion of extended ASCII codes into the Text property of objects within the badge layout. Database/Text Box Typeface (Font, Size, Color, Bold, Italic, Underline) Case Options (Upper Case, Lower Case, Mixed Case) Border (Type, Width, Color) Fill Color and Style Alignment of Text (Horizontal and Vertical) Maximum Number of Characters Object Positioning on the Credential Scale to Fit Inside Object Word Wrap (Yes, No) Object Visibility (Yes, No)

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 247

SECTION II
Photo Border (Type, Width, Color) Fill Color and Style Ghost Factor Chromakey (Yes, No) Alignment (Horizontal, Vertical)

FUNCTIONAL REQUIREMENTS

Horizontal and Vertical Tile (Yes, No) Horizontal and Vertical Tile to Fit (Yes, No) Object Positioning Number of Horizontal and Vertical Tile Rows and Columns Preserve Aspect Ratio (Yes, No) Object Visibility (Yes, No) Border (Type, Width, Color) Fill Color and Style Ghost Factor Chromakey (Yes, No) Which Graphic is Displayed on the Credential Alignment (Horizontal, Vertical) Horizontal and Vertical Tile (Yes, No) Horizontal and Vertical Tile to Fit (Yes, No) Object Positioning Number of Horizontal and Vertical Tile Rows and Columns Preserve Aspect Ratio (Yes, No) Object Visibility (Yes, No) Bar-Code Format Border (Type, Width, Color) Fill Color and Style Object Positioning Rotation

Graphic

Bar-Code

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 248

SECTION II
Shape Border (Type, Width, Color) Fill Color and Style Object Positioning Visibility Encoded Information Visibility (Yes, No) Border (Type, Width, Color) Fill Color and Style Signature Color Alignment (Horizontal, Vertical)

FUNCTIONAL REQUIREMENTS

Signature

Horizontal and Vertical Tile (Yes, No) Horizontal and Vertical Tile to Fit (Yes, No) Object Positioning Number of Horizontal and Vertical Tile Rows and Columns Preserve Aspect Ratio Signature Pen Width Chromakey Object Visibility

c) Bar-code Support The SYSTEM shall support the following bar codes as standard in the software: Code 3 of 9 (3:1) Code 93 UPCA EAN 13 EAN 8 Code 128 A Code 128 B Code 128 C Codabar PostNet (Zip +4 Postal) Code 3 of 9 (2:1) Interleaved 2 of 5 (2:1) Code 128 Auto PDF-417 (2D) UCC-128 MSI Plessey

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 249

SECTION II
Code 3 of 9 (3:1) Extended Code 3 of 9

FUNCTIONAL REQUIREMENTS
Extended Code 93

d) Object Properties System Administrators shall have the ability to edit each object placed onto the layout using a Properties Form to customize each object on the layout. 1) Text and Database Objects System Administrators shall be able to adjust the positioning of the object, its height and width, along with the objects color and color fill style (solid, horizontal lines, etc.). Borders (if any), along with the border width and border style shall also be modifiable. The typeface of any text shall be user definable (font, size, bold, italic, underline) as well as the alignment of the text inside of the object (left, center, right, top, middle, bottom). System Administrators shall be able to allow word wrapping of text within the object and shall be allowed to set the maximum number of characters allowed in the object. 2) Photo, Signature, and Graphic (logo) Objects System Administrators shall be able to adjust the positioning of the object, its height and width, along with the object's color and color fill style (solid, horizontal lines, etc.). Borders (if any), along with the border width and border style shall also be modifiable. Attributes shall be available for auto sizing and scaling the photo, signature, or graphic that shall be located in the object. Keeping aspect ratio shall be an option. Alignment of the photo, signature, or graphic inside of the object (left, center, right, top, middle, and bottom) shall be available. System Administrators shall also be able to chromakey and/or ghost the photo or graphic. System Administrators shall also be able to tile the image or logo in any number of rows and columns across the background of the credential. 3) Shape Objects System Administrators shall be able to adjust the positioning of the object, its height and width, along with the object's color and color fill style (solid, horizontal lines, etc.). Borders (if any), along with the border width and border style shall also be modifiable. System Administrators shall have the option of inserting square, circle, rectangle, or ellipse shapes. 4) Bar-code Objects System Administrators shall be able to adjust the positioning of the object, its height and width, along with the object's color and color fill style (solid, horizontal lines, etc.). Borders (if any), along with the border width and border style shall also be modifiable. System Administrators shall have the ability to rotate the bar-code to a vertical or horizontal position on the layout. The SYSTEM shall allow System Administrators to encode any database field and/or other information onto the bar-code, depending on the bar-code type selected. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 250

SECTION II
e) Object List

FUNCTIONAL REQUIREMENTS

An object list shall be available to System Operators to allow them to select objects without clicking on them in the layout with the mouse. This shall be helpful when one object has been placed onto top of the other, making it difficult to select the object in the background with the mouse; or when System Operators wish to select an object without moving the objects position on the layout. f) Color Palette The SYSTEM shall support a Windows Color Palette capable of creating up to 16.7 million colors to be used in applying color to the various objects, shading, and/or borders in the badge layout. g) Import/ of Badge Layouts The SYSTEM shall also allow for the importing of badges from a .bdg file. h) Multiple Badge per Page Printing The SYSTEM shall allow for System Operators to print multiple badges to the same page. System Administrators can configure the SYSTEM to print multiple badges to a pre-defined number of columns and rows to accomplish 2 up, 4 up, 6 up, or 8 up printing. This feature is useful when printing badges for visitors. i) Working with Objects A set of alignment tools shall be available to System Administrators to manage objects. Move to Front, Send to Back, Move Forward, and Move Backward commands shall be available to allow objects to be placed on top of other objects. The SYSTEM shall support the rotation of objects in 90 degree increments (0, 90, 180, 270. A zoom command shall be available to allow System Administrators to manage the layout in multiple views. User definable sample field data shall be available for ease of working with objects. When objects are placed onto a layout, the sample data will fill in to show the System Administrator what effect the object has on the layout. System Administrators shall also be able to select the color of the PVC card that they are working with so they will see the effect that it has on the layout. They shall also be able to place the magnetic stripe outline on to the layout for ease of aligning other objects. All Badge Layouts shall be placed in a gallery for previewing.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 251

SECTION II 15. Screen Designer Tool

FUNCTIONAL REQUIREMENTS

a) SYSTEM Cardholder Standard Fields and Objects The SYSTEM shall support at a minimum the following standard fields for personnel information: Last Name First Name Middle Initial Social Security # Badge Type Address 1 Address 2 City State Zip Code Phone # Birth Date Title Department Division Location Building Floor Office Phone # Extension Signature Last Reader Accessed Record Last Changed Badge ID Issue Code Number of Prints Activation Date Deactivation Date/Time Badge Status PIN Number Embossed Number Date of Last Badge Print Photo Photo Display

b) SYSTEM Asset Standard Fields and Objects SYSTEM shall support at a minimum the following standard fields for asset information: Scan ID Asset Name Acquired Replace Type Subtype Serial Number Department Replacement Value Last Inspection Next Inspection Record Last Changed Photo Photo Display Last Reader Accessed

Assessed Value

Assignment Button

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 252

SECTION II

FUNCTIONAL REQUIREMENTS

c) SYSTEM Visitor Standard Fields and Objects SYSTEM shall support at a minimum the following standard fields for visitor information: Last Name First Name Middle Initial Badge Type Organization Title Address 1 Address 2 City State Zip Code Office Phone Extension Last Changed Last Reader Accessed Record Last Changed Badge ID Issue Code Number of Prints Activation Date Deactivation Date/Time Badge Status Photo Photo Display

d) SYSTEM Visit Standard Fields and Objects Host Name Visitor Name Status Scheduled Time In Scheduled Time Out Purpose Actual Time In Actual Time Out Last Changed Type

e) User Definable Fields Should the SYSTEM standard fields not be suitable, System Administrators shall have the ability to modify any standard field to customize the cardholder, asset, and visitor forms as desired. The SYSTEM shall also allow System Administrators to add custom fields in addition to or replacement of any standard fields on a minimum of thirty two (32) pages each of information for the cardholder, visitor, and visit forms and one page of information for asset. User defined fields absolutely shall not be pre-defined, meaning only the labels can change while the properties cannot. System Administrators shall have a minimum of sixteen pages of which to design their screens with standard and custom fields. System Administrators shall have the ability to modify the pages of information in any combination as follows:

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 253

SECTION II

FUNCTIONAL REQUIREMENTS
Move standard database fields to different locations on the cardholder forms Delete standard database fields that are not desired Keep standard database fields in the same location as the factory ships them, but changing the label and/or any field attributes. For example, Zip Code may be changed to Postal Code and the attributes changed from a number field to text field for Canadian Installations Add new fields to the cardholder forms each with their own unique set of attributes

f) Field Types The SYSTEM shall support, at a minimum, the following field types: Text Fields Date Fields Numeric Fields Drop Down Lists

g) Field Attributes System Administrators shall be able to assign any combination of the following attributes to each field defined: Positioning of the field on the form From which page the field can be viewed From which page the field can be edited The font to be used for the information that will appear in the field. The SYSTEM shall support all standard Windows fonts The style to be used for information that will appear in the field. The SYSTEM shall support bold, italic, both, and regular typeface styles Any effects to be used for the information that will appear in the field. The SYSTEM shall support strikeout and underline Whether the field is required Whether the field is to be indexed Whether the field is unique If a template is to appear in the field If a default value will appear in the field

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 254

SECTION II
h) Field Styles

FUNCTIONAL REQUIREMENTS

System Administrators shall be able to assign any combination of the following styles to each field defined: Multi-line field Horizontal Scroll Vertical Scroll Auto Horizontal Scroll Auto Vertical Scroll Enter means next line of text Number Uppercase Lowercase Read Only Align Right Password Sunken Border Inside Edge Raised OEM Covert

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 255

SECTION II
i) Field Alignment and Width Tools

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support the following field alignment tools to allow System Administrators to align fields and set uniform widths to fine tune the look and feel of the screens. The SYSTEM shall allow System Administrators to select multiple objects simultaneously and align them to their desired position and/or set a uniform width. The following field alignment tools shall be able to be used in any combination: 1. Align all objects selected to the far left edge of the farthest left selected object 2. Align all right edges of selected objects to the right edge of the farthest right selected object 3. Align the tops of all selected objects to the top edge of the highest selected object 4. Align the bottom edges of all selected objects to the bottom edge of the lowest selected object 5. Align all selected objects to be vertically centered with respect to each other 6. Center all selected objects 7. Make all selected objects the same width as the smallest object selected 8. Make all selected objects the same width as the widest object selected 9. Make all selected objects the same height as the shortest object selected 10. Make all selected objects the same height as the tallest object selected 11. Evenly space all objects vertically between the two most outer objects 12. Evenly space all objects horizontally between the two most outer objects 13. Bring object to the front of the page 14. Send object to the back of the page j) Tab Ordering The SYSTEM shall allow System Administrators to set the TAB order (the order in which the cursor moves throughout the fields) of the SYSTEM when System Operators utilize the TAB key to move throughout the cardholder form.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 256

SECTION II 16. Map Editor Module

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support graphical map creation software that shall allow the import of map backgrounds from any standard off-the-shelf drawing package in the formats listed below: AutoCAD DXF (.dxf) Bitmaps (.bmp, .dib) JPEG (.jpg) JIFF (.jif) Zsoft PCX/DCX (.pcx, .dcx) Adobe Photoshop (.psd) CALS Raster (.cal) GEM/Ventura IMG (.img) IBM IOCA (.ica) WordPerfect Raster (.wpg) Macintosh PICT (.pct) Portable Network Graphics (.png) TIFF (.tif) Windows Metafile (.wmf, .emf) Targa (.tga) Kodak Photo CD (.pcd) Kodak Flashpix (.fpx) Encapsulated Post Script (.eps)

These architectural type maps must allow the detailed layout of an entire structure, part of a structure, a floor or department within a building, or layout of the periphery of a facility. Once a map has been drawn, the System Administrator must have the ability to place system level icons of card readers, input & output points, video cameras, and other access control field hardware in the appropriate area to indicate their respective location on the map. This is to be accomplished by simply dragging the icon with the mouse to the appropriate location on the map. The SYSTEM must allow various maps to be associated with each area to provide for the creation of hierarchy of maps. Overview maps of an entire facility shall be able to be viewed as requested and nested maps shall be accessed from the overview map to enlarge a specific area or facility on the screen. Maps shall also support user defined text that shall be placed onto the map background. The SYSTEM shall allow hardware device icons to be either static or part of a device group. Icons that are part of a device group shall allow the hardware device icon to change shape and/or color based on the current state of the device. Maps shall have the ability to be printed and/or previewed from the Map Editing Module or the Alarm Monitoring Module. The SYSTEM shall also support custom device icons to be used with the maps (.ico) files.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 257

SECTION II 17. Import Module

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support, as a mandatory requirement, an import utility, which shall allow the CUSTOMER or VAR to import cardholder information into the SYSTEM database. This shall allow the CUSTOMER or VAR to pre-populate the SYSTEM database with existing cardholder data and/or add NEW records to an existing SYSTEM database. The Import Utility shall be a 32-bit Windows application that shall be used to import standard ASCII delimited text files into the SYSTEM. The import utility shall be utilized at the initial SYSTEM setup and anytime a large number of records need to be imported into the SYSTEM after the initial import. For example, a large university may import 10,000 records into the SYSTEM during the initial SYSTEM setup and then import 2,000 additional records each semester thereafter. The SYSTEM shall check for duplicate records during the import, so that multiple copies of the same record are not added into the SYSTEM database. The import utility shall allow System Administrators to choose the delimiter for the ASCII file. This delimiter may be, but is not limited to, a comma, vertical bar, semi-colon, or asterisk. Fields in the SYSTEM database, such as Address 2, that the CUSTOMER does not wish to use, may be left blank in the ASCII file. The import utility shall be able to select the source drive where the ASCII delimited file is located as well as the destination drive where the SYSTEM database is located. The import utility shall also be able to import photos as part of the record into the SYSTEM database. The SYSTEM shall support the following file formats for the import of cardholder photos: Bitmaps (.bmp, .dib) JPEG (.jpg) JIFF (.jif) Zsoft PCX/DCX (.pcx, .dcx) Adobe Photoshop (.psd) CALS Raster (.cal) GEM/Ventura IMG (.img) IBM IOCA (.ica) Macintosh PICT (.pct) Portable Network Graphics (.png) TIFF (.tif) Windows Metafile (.wmf, .emf) Targa (.tga) Kodak Photo CD (.pcd) Kodak Flashpix (.fpx) Encapsulated Post Script (.eps)

WordPerfect Raster (.wpg) The SYSTEM shall include a progress meter to show the System Administrator the percentage of the import complete when importing large quantities of records.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 258

SECTION II 18. DataExchange

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support, as a mandatory requirement, an import/export utility that shall enable advanced System Administrators to import data and images into the SYSTEM database and export data and images from the SYSTEM database for use with third party software systems. The DataExchange Utility shall allow for bi-directional communications with external systems. It shall allow for the import into the SYSTEM database and the export out of the SYSTEM database personnel information, including images, through ASCII delimited files or XML files. The import/export scripts shall run on schedule and shall be accomplished over the network. DataExchange is ideal for customers who wish to have a base line level of integration with third party external systems such as those used for Time & Attendance and Debit Card systems. Database import and export scripts shall be stored in the SYSTEM database. A user interface shall allow for the generation of import and export scripts. When configuring/running a DataExchange script, the SYSTEM shall alert the System Administrator if deprecated fields are being used. The file used for import or created by export shall have the ability to be structured in a wide variety of ways, but shall always be in either ASCII text, Unicode text, XML, or Database format. System Administrators can configure the import procedures to put the new data into any of the tables of the SYSTEM database. As such, export data shall be taken from any tables in the SYSTEM database. a) File Imports DataExchange shall allow data to be imported into the SYSTEM database. Importing of information shall occur in one or more of the following methods: 1. Add - The data in the file shall be added to the database. If a particular record is already in the database, an error shall occur and the record shall be rejected and placed in an error log. 2. Change - If a record in the file exists in the database, the record shall be modified according to the layout configuration specified. Records in the file that dont already exist in the database shall be rejected and placed in an error log file. 3. Delete - If a record in the file exists in the database, it shall be deleted. 4. Add/Modify - If a record in the file exists in the database, it shall be replaced according to the layout configuration you specified. Records that dont already exist shall be added to the database.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 259

SECTION II

FUNCTIONAL REQUIREMENTS

DataExchange shall support a minimum of the following image file formats to be imported into the SYSTEM database:
Adobe Photoshop 3.0 CALS Raster Delrina WinFax Group 3 Delrina WinFax Group 4 Encapsulated PostScript FAX Group 3 FAX Group 4 GEM Image IOCA or IBM Image Object Content Architecture JIFF or JPEG File Interchange Format JPEG Tagged Interchange Format Kodak FlashPix Kodak PhotoCD LEAD CMP Macintosh Pict Format MacPaint OS/2 Bitmap Portable Network Graphics SUN Raster Format Truevision TARGA Microsoft Paint Windows Bitmap WordPerfect Format Zsoft PCX/Multipage PCX PSD CAL FAX FAX EPS FAX FAX IMG ICA JPG/JIF JTIF FPX PCD CMP PCT MAC BMP PNG RAS TGA MSP BMP WPG PCX/DCX

DataExchange shall utilize an error log that shall report all errors that occur during a file import. Any and all errors can then be viewed from this log, corrected, and the import shall run a second time to download the corrected records. DataExchange must allow imported changes to be downloaded to Intelligent System Controllers on a near real-time basis as information is being imported into the database. b) Exporting Data DataExchange shall allow data to be exported from the SYSTEM database. Any combination of SYSTEM database fields shall have the ability to be exported to a Database or Unicode text file.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 260

SECTION II
c) Data Expressions

FUNCTIONAL REQUIREMENTS

DataExchange shall support run-time data generation to support customer business logic. Following expression types shall be provided: 1) Constants This type of expression shall provide import or export with data that doesnt change like 5 or Employee. The System Administrator shall configure the value. Constant expressions shall be able to be parts of other expressions. 2) Increments Similar to numerical constants, but change as import or export progresses. For example: 1 for the first record, 3 for the second, 5 for the third etc. The System Administrator shall configure a base value (1 in example) and increment (2 in example). 3) Lookups Lookup expressions query the SYSTEM database with System Administrator provided data and return query result. For example, System Administrator data contains a department name such as Engineering, but to import a record department ID is needed. The System Administrator shall configure a lookup on DEPT table with NAME as a source field and ID as a return field. So lookup with Engineering will return 2. Lookup expressions shall be cascaded or be parts of other expressions (such as conditional expressions). Lookups shall be user configured to add records to a lookup table if value is not found. 4) Conditional expressions Conditional expressions evaluate a comparison between two pieces of data to either a true or false result, and based on that result return one or the other configured user data. Conditional expressions can be cascaded or be parts of other expressions (such as lookup expressions). An example of an expression returning file data would be something like the imported data wants to use the default badge type business rule for the deactivate date when adding a new badge. However, if a badge already exists for the cardholder, use its deactivate date.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 261

SECTION II
d) Import/Export Filters

FUNCTIONAL REQUIREMENTS

The DataExchange shall allow System Administrators to select a subset of data for export or database import operations. SQL filter shall be used do define which records would be selected for the import or export.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 262

SECTION II 19. SYSTEM Server Redundancy

FUNCTIONAL REQUIREMENTS

The SYSTEM shall support multiple levels of fault tolerance and SYSTEM redundancy listed and described below:

Fault Tolerant Servers Hot Standby Servers Microsoft Clustering Disk Mirroring RAID Level 10 Distributed Intelligence

a) Fault Tolerant Servers The SYSTEM shall support the NEC Express 5800 320 Series server with Intel Xeon series processors. The Server shall be a self-contained fully redundant system (dual module/mirrored components) with on-line serviceability and hot-swappable replacement of all major subsystems including processors, power supplies, PCI bus and SCSI controllers. The server shall provide 99.999% system up time and include the following list of features/hardware: Each of the two modules shall support a minimum of one and a maximum of two Intel Xeon processors at a minimum clock rate of 2.4GHz with the ability to upgrade from one processor to two processors. Processors in each of the two modules shall be synchronized to perform the same instructions at the same time. b) Hot Standby Server Solution (For Use with LAN based ISCs and SQL Server RDBMS only) The SYSTEM shall support a fault tolerant server and redundant database architecture. It shall allow for normal operations to occur in the event that the Database Server fails. In the event of a server failure, the switch over to a backup server shall be automatic. System Operator intervention for switch over shall not be acceptable. The SYSTEM shall utilize two servers, which shall be configured identically. One server shall be designated as the Primary Server and the other shall be designated as the Backup Server. The Primary Server shall be the main server that is in use when the SYSTEM is operating under normal conditions. The SYSTEM shall mirror the database information from the Primary Server to the Backup Server. This mirroring shall be conducted through standard local area network (LAN) communications. There shall absolutely not be any proprietary communication links between the Primary and Backup Servers.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 263

SECTION II

FUNCTIONAL REQUIREMENTS

All access control field hardware shall be configured for both the Primary Server and the Backup Server. Both the Primary and Backup Servers shall recognize the same TCP/IP ISC address on the network. If the Backup Server is not running or receiving the mirrored files from the Primary Server, the Primary Server shall save the changes locally. Upon restored communications to the Backup Server, this information shall be automatically sent to the Backup Server. In the event that the Primary Server fails, the Backup Server shall sense that the Primary Server has failed and is no longer on the network. The Backup Server shall check to see if the Primary Server is on line every five seconds. Upon sensing Primary Server failure, the Backup Server shall automatically initiate itself as the Primary Server and shall begin communication with the Intelligent Fields Panels. ABSOLUTELY NO SYSTEM OPERATOR INTERVENTION SHALL BE REQUIRED. A message shall be broadcast to all client workstations on the network that the Primary Server has failed and the Backup Server has taken control. This process shall take no longer than two minutes to accomplish. Once the Primary Server comes back on-line with the SYSTEM, the Primary Server and Backup Server shall be able to be re-synchronized though automatic operation and resume normal operations. The synchronization process shall be fast, efficient, and take no more than five minutes. c) Clustering (FOR USE WITH MICROSOFT WINDOWS ADVANCED SERVER) The SYSTEM shall support a fault tolerant cluster server architecture. It shall allow for normal operations to occur in the event that the Database Server fails. In the event of a server failure, the switch over to a backup server shall be automatic. System Operator intervention for switch over shall not be acceptable. The SYSTEM shall utilize two servers, which shall be configured identically. One server shall be designated as the Primary Server and the other shall be designated as the Backup Server. The Primary Server shall be the main server that is in use when the SYSTEM is operating under normal conditions. The SYSTEM shall use shared-media technology. This shall incorporate a third-piece of hardware (e.g. Dell PowerVault), which shall house the hard disk to be referenced by both servers. Since accessible media is dependent upon a third-piece of hardware, emphasis shall only placed upon the health status of the shared-media device. If the status of the shared-media device remains healthy, server up time is of no consequence to data integrity. The shared-media device provides only a single point of failure. If this device fails, then data cannot be accessed. A dual point of failure shall be achieved by incorporating two shared-media devices that are mirrored (e.g. two stacked mirrored Dell PowerVaults).

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 264

SECTION II

FUNCTIONAL REQUIREMENTS

All access control field hardware shall be configured for both the Primary Server and the Backup Server. Both the Primary and Backup Servers shall recognize the same TCP/IP ISC address on the network. In the event that the Primary Server fails, the Backup Server shall sense that the Primary Server has failed and is no longer on the network. The Backup Server shall check to see if the Primary Server is on line every 5 seconds. Upon sensing Primary Server failure, the Backup Server shall automatically initiate itself as the Primary Server and shall begin communication with the Intelligent Fields Panels. ABSOLUTELY NO SYSTEM OPERATOR INTERVENTION SHALL BE REQUIRED. A message shall be broadcast to all client workstations on the network that the Primary Server has failed and the Backup Server has taken control. This process shall take no longer than 2 minutes to accomplish. Once the Primary Server comes back on-line with the SYSTEM, the Primary Server shall resume normal operations. d) Disk Mirroring The SYSTEM database server shall protect data against failure of a hard disk or hard disk controller by providing a disk mirroring configuration. The disk mirroring configuration shall allow data to be stored on dual hard disks running simultaneously. When any client workstation or Intelligent System Controller sends data to the database server, it shall be stored to both sets of hard disk drives. In the event any component on one channel fails, the other disk drive continues to operate without data loss or interruption. The SYSTEM shall also send a warning message indicating that one disk drive has failed. e) RAID Level 10 The SYSTEM shall offer a Fault Tolerant Redundant Array of Independent Disks Level 10 (RAID Level 10) with a hot standby disk. RAID Level 10 shall provide redundancy of disk storage, controller channels and power supplies. Each array must contain a disk drive, high efficiency power supply, and cooling fan. This technology shall use multiple drives to store data with distributed parity, thereby ensuring data protection in an environment in which data is safe and easily restorable in the event of a hard disk failure. In the event a single drive within the array fails, a "Hot Standby Hard Disk" shall be available on-line and automatically switched with the failed unit. The network administrator shall be able to replace the failed drive without taking the database server down, and it shall then become the hot standby. The array software shall rebuild the lost data from parity information stored on the other drives in the array. This entire procedure shall have no effect on the operation of the SYSTEM and shall be automated.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 265

SECTION II
f) Distributed Intelligence

FUNCTIONAL REQUIREMENTS

In the event SYSTEM communications is lost or the database server fails, Intelligent System Controllers shall provide complete control, operation and supervision of all monitoring and control points. The ISC shall be configured with a UPS battery, which shall support the ISC for a 24 hour duration. The ISC shall be installed with enough memory to support up to 10,000 cardholders/100,000 events in a minimum configuration and be expandable to up to 250,000 cardholders/1,000,000,000 events. The SYSTEM shall incorporate performance tests and precautions so as to avoid SYSTEM failure. In the event of a failure, transactions are to be stored in an ISC First In First Out (FIFO) buffer until the ISC comes back on-line, at which time all data is uploaded to the database server. The ISC shall register as on-line with the database server when communications are re-established. Should the ISC buffer fill and events are overwritten, an event will appear in the Main Alarm Monitoring Window notifying the System Operator that events were overwritten. The ISC shall send a time/date stamp of the last record/table update in its memory and request any new data changes or cardholder records which have changed since that time/date stamp. A complete download of database and access tables shall not be required because of off-line operation.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 266

SECTION II 20. DataConduIT

FUNCTIONAL REQUIREMENTS

The SYSTEM shall allow, through standard API toolkits, System Administrators to expose specific SYSTEM data and events that are relevant to IT information or other third party systems. Conversely, the SYSTEM shall allow, through these same API toolkits, System Administrators to accept and process information exposed from the IT information or other third party systems. This shall permit System Administrators to develop scripts and applications that allow events in either the IT domain to cause appropriate actions in the Security domain, and vice versa. Using the toolkit, the following shall be a sample of the integration opportunities available:
1.

When a cardholder account is created in the SYSTEM, DataConduIT shall create a Windows 2008/2003/XP/Active Directory Account for that person. The Windows account name shall be derived from the SYSTEM cardholder name. The SYSTEM account and the Windows account shall then be linked to the same person. When a users Windows 2008/2003/XP/Active Directory Account is created, DataConduIT shall create a SYSTEM cardholder account, badge, and access rights. The SYSTEM account and the Windows account shall then be linked to the same person. A cardholders phone number changes in the SYSTEM. The new phone number shall be propagated through DataConduIT to the associated user account in the companys Active Directory. When a cardholders access badge is disabled, DataConduIT shall automatically disable that cardholders other IT user accounts. Conversely when a users Windows or other Active Directory/LDAP account is disabled, DataConduIT shall deactivate the cardholders access badge in the SYSTEM. A users Windows account for PCs in a research lab is normally deactivated. When a cardholder cards into the research lab, DataConduIT shall activate the users Windows account for the computers in the research lab. A 3rd party system acknowledgment of pending alarms in the SYSTEM database.

2.

3.

4.

5.

6.

All business rules pertaining to cardholders, badges, access levels, and linked accounts shall be enforced when a cardholder, badge, access level, or linked account is added, modified, or deleted. Clients shall not be able to make any writes that would be invalid if made through the SYSTEMs System Administration module. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 267

SECTION II
a) SYSTEM API Toolkit Operations 1) Operations

FUNCTIONAL REQUIREMENTS

DataConduIT clients shall be able to add new cardholders and modify or delete existing cardholders, visitors, visits, biometrics, and images. DataConduIT clients shall be able to add new badges and modify or delete existing badges. DataConduIT clients shall be able to add and delete linked accounts. Modification of existing linked accounts shall not be permitted. DataConduIT clients shall be able to view directory definitions. Modification of existing directories shall not be permitted. 2) Software Events DataConduIT clients shall be able to register to receive notification when any of the following software events takes place:
1.

A person is added, modified, or deleted (including the person primary segment assignment) A badge is added or deleted, or its badge status changes A linked account is added or deleted 3) Hardware Events

2. 3.

DataConduIT clients shall be able to register to receive notification when any access control field hardware events takes place. This shall include access to areas, elevator readers, and assets, and for access attempts under duress. This shall include the acknowledgment of pending alarms in the SYSTEM database. b) Accepting Custom Incoming Alarms and Events The SYSTEM shall accept generic/custom incoming events from 3rd party systems to be displayed in the Main Alarm Monitoring Window, similar to other SYSTEM alarms. In addition, it shall be possible to configure where to route these alarms. The SYSTEM shall allow the Main Alarm Monitoring Window to represent the following:
1.

Source a text representation of the object or device that generated the event Date/Time the date and time when the event occurred LENEL - A UTC FIRE & SECURITY COMPANY

2.

OnGuard

Functional Specifications Version 6.3 Series

Page 268

SECTION II
3.

FUNCTIONAL REQUIREMENTS
Description text of up to 80 characters that describes the event

4.

Additional Text additional text of up to 1,000 characters associated with the event

c) DataConduIT Devices and Sub-Devices The SYSTEM shall be able to support downstream devices and sub-devices through DataConduIT. The configuration for these devices shall occur in the DataConduIT Source folder in System Administration. Event Generation with Devices and Sub-Devices The SYSTEM shall be able to generate Access Granted and Access Denied events from an DataConduIT source, Device, or Sub-Device. The SYSTEM shall also be able to pass the badge identification number along with the access granted or denied. This shall report to the DataConduIT source.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 269

SECTION II 21. Open Protocol Interface

FUNCTIONAL REQUIREMENTS

The SYSTEM shall provide a set of standard Application Programming Interfaces (API's) and supporting documentation that allows hardware manufacturers and software application developers to interface their products into the SYSTEM. The Application Programming Interfaces shall allow requests to occur from CUSTOMER to interface a third party hardware or software solution based on SYSTEM open architecture and SYSTEM device independence. There shall be two components to the Application Programming Interfaces. There shall be a device interface and an application interface. The device interface shall allow extensibility to the number and types of hardware devices supported by the SYSTEM. Each individual piece of hardware shall have its own driver that shall understand how to communicate with the SYSTEM hardware. These drivers or "device translators" shall translate a set of generic commands into specific device commands. The device translators shall be implemented as COM (Component Object Model) objects so that they shall be loaded and unloaded as needed. Each device translator shall support certain interfaces that support a specific set of commands or methods. Some examples of typical interfaces could include an Access Control Interface for access control hardware, a Video Interface for DVR and NVR hardware, an Intercom Interface for intercom systems, an Intrusion Interface to support alarm inputs, etc. A particular device translator shall support many interfaces. The main application that shall be used to control the various device translators is the SYSTEM Communication Server (SCS). The SCS shall be the application that manages and sends the commands to the device translators. Other modules including Alarm Monitoring or System Administration shall communicate with the hardware devices by sending commands to the SYSTEM Communication Server, which shall then send the commands on to the correct device or devices. The device interface shall allow the software interface of any hardware device to be controlled and monitored via the SYSTEM Alarm Monitoring module. This shall preserve customer investments in existing equipment as well as allow for system expansion to occur through the interface of the latest hardware technologies. The application interface shall allow information to be exchanged between the SYSTEM and other applications. The application interface shall provide the functions for interacting with the SYSTEM. This includes the ability to extract information from the SYSTEM database as well the ability to download, control and monitor information for all field hardware including access control panels, digital video systems, fire panels, alarm panels, intercom system, etc.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 270

SECTION II

FUNCTIONAL REQUIREMENTS

All functions of the application interface shall be defined in such a way that any Windows application or development environment with the ability to make C calls should be capable of making use of the API.

22.Open Supervised Reader Interface

The SYSTEM shall provide connectivity to proximity and smartcard readers which provide continuous supervision and monitoring of reader processor and wiring integrity by means of a non-proprietary communications protocol standard. Supervision methods that simply supervise wiring or measure current draw are not acceptable, since they do not insure that the readers microprocessor is actually operational. Likewise, proprietary protocols which are sole sourced or licensed for a fee are not acceptable, since they limit potential future expansion options for the SYSTEM. The preferred protocol is the Open Supervised Device Protocol (OSDP), since it is nonproprietary and meets the requirements stated above. Alternative supervised reader interface protocols will be considered only if they meet all of the technical requirements of this section AND can be shown to be non-proprietary.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 271

SECTION III
CLIENT WORKSTATION & PERIPHERAL SPECIFICATIONS

SECTION III

WORKSTATION & PERIPHERAL REQUIREMENTS

Section III - WORKSTATION & PERIPHERAL REQUIREMENTS

The SYSTEM shall integrate all access control, credential management, digital video management, intrusion detection management, asset management, and visitor management functionality into a single database in a networked environment. The SYSTEM shall allow the incorporation and integration of servers, access control client workstations, badging client workstations, asset management client workstations, digital video management client workstations, intrusion detection management client workstations, visitor management client workstations, remote access level management client workstations, and integrated client workstations sharing the same database on local area or wide area networks. The SYSTEM shall allow future expansion to include additional client workstations without losing functionality. SYSTEM administrative operations shall be available from any client workstation on the SYSTEM that is configured and licensed to do so. System Administrator functions include the creation of maps, alarm response instructions, access levels, time zones, holidays, reports, area control, outputs, and all required SYSTEM configurations. System Administration operations shall include changes/configuration to the CCTV image comparison screen, cardholder window, employee capture, and cardholder look-up screen. The Windows 2008/2003 based servers shall support client workstations that shall be configured to operate on the Windows Vista or XP platform. Integrated client workstations shall be configured to perform any combination of tasks based on licensing of the product. For example, a client workstation shall be configured to be an alarm monitoring, system configuration, and enrollment client workstation. Other client workstations shall be defined as alarm monitoring only. All Windows 2008/2003 based systems MUST be used in conjunction with a client/server relational database management system such as Microsoft SQL Server 2005 or Microsoft SQL Server 2008 or Oracle Server 10g or 11g. All PC specifications are based on the Intel Pentium chip technology and, due to the dynamic nature of the computer industry, subject to change with industry standards. The following are the minimum required specifications for all PC servers and Client workstations.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 273

SECTION III
A. Database Servers

WORKSTATION & PERIPHERAL REQUIREMENTS

1. Servers for Windows 2008/2003 Access Control & Alarm Monitoring Systems All Total Security Knowledge Management System data shall reside on the database server. Also, all database and query processing shall take place at the server. The database server can also be utilized as a workstation with full alarm monitoring and administrative capabilities. Intelligent System Controllers shall be connected to the database server. The database server shall operate on the Windows 2008/2003 Server System platform and utilize Microsoft SQL Server 2005 as its Relational Database Management System. The Database Server for Windows 2008/2003 Access Control & Alarm Monitoring Systems shall consist of the following minimum specifications: PC Specifications

Intel Quad Core Xeon E5410, 2.33GHz, 2x6MB L2 Cache, 1333MHz FSB 2GB 667MHz (2 X 1MB) Single Ranked Fully Buffered DIMMs 24X IDE CD-RW/DVD ROM Drive 73GB 15K RPM SerialAttach SCSI 3Gbps 2.5-in Hot Plug Hard Drive Dual 10/100/1000 Ethernet Network Ports 17 Flat LCD Monitor 64 MB Dual Monitor Video Card 1 serial port 1 parallel port 6 USB 2.0 ports Speakers USB Keyboard USB Optical Mouse Surge Suppression Strip

Server Software

Microsoft Windows 2008/2003 Server Operating System Microsoft SQL Server 2005 Relational Database Management System SYSTEM Server Software for Windows 2008/2003

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 274

SECTION III

WORKSTATION & PERIPHERAL REQUIREMENTS

2. Servers for Windows 2008/2003 PRO Access Control & Alarm Monitoring Systems All total security knowledge management system data shall reside on the database server. Also, all database & query processing shall take place at the database server. Intelligent System Controllers can be connected to the database server. The server shall operate on the Windows 2008/2003 Server System platform and utilize Microsoft SQL Server 2005 as the Relational Database Management System. The Database Server for Windows 2008/2003 Access Control & Alarm Monitoring Systems shall consist of the following minimum specifications: PC Specifications

Intel Quad Core Xeon E5410, 2.33GHz, 2x6MB L2 Cache, 1333MHz FSB 2GB 667MHz (2 X 1MB) Single Ranked Fully Buffered DIMMs 24X IDE CD-RW/DVD ROM Drive 73GB 15K RPM Serial-Attach SCSI 3Gbps 2.5-in Hot Plug Hard Drive Dual 10/100/1000 Ethernet Network Ports 17 Flat LCD Monitor 64 MB Dual Monitor Video Card 1 serial port 1 parallel port 6 USB 2.0 ports Speakers USB Keyboard USB Optical Mouse Surge Suppression Strip

Server Software

Microsoft Windows 2008/2003 Server Microsoft SQL Server 2005 Relational Database Management System SYSTEM Server Software for Windows 2008/2003

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 275

SECTION III

WORKSTATION & PERIPHERAL REQUIREMENTS

3. Servers for Windows 2008/2003 Credential Management Systems All personnel data shall reside on the database Server. Also, all database & query processing shall take place at the server. The database server can also be utilized as a workstation with full imaging, display, editing, and administrative capabilities. The server shall operate on the Windows 2008/2003 Server System platform and utilize Microsoft SQL Server 2005 as its Relational Database Management System. The Database Server for Windows 2008/2003 Credential Management Systems shall consist of the following minimum specifications: PC Specifications

Intel Quad Core Xeon E5410, 2.33GHz, 2x6MB L2 Cache, 1333MHz FSB 2GB 667MHz (2 X 1MB) Single Ranked Fully Buffered DIMMs 24X IDE CD-RW/DVD ROM Drive 73GB 15K RPM Serial-Attach SCSI 3Gbps 2.5-in Hot Plug Hard Drive Dual 10/100/1000 Ethernet Network Ports 17 Flat LCD Monitor 64 MB Dual Monitor Video Card 1 serial port 1 parallel port 6 USB 2.0 ports Speakers USB Keyboard USB Optical Mouse Surge Suppression Strip

Server Software

Microsoft Windows 2008/2003 Server Operating System Microsoft SQL Server 2005 Relational Database Management System SYSTEM Server Software for Windows 2008/2003

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 276

SECTION III

WORKSTATION & PERIPHERAL REQUIREMENTS

4. Servers for Windows 2008/2003 Credential Management Systems All personnel data shall reside on the database server. Also, all database & query processing shall take place at the database server. The server shall operate on the Windows 2008/2003 Server System platform and utilize Microsoft SQL Server 2005 as the Relational Database Management System. The Database Server for Windows 2008/2003 Credential Management Systems shall consist of the following minimum specifications: PC Specifications

Intel Quad Core Xeon E5410, 2.33GHz, 2x6MB L2 Cache, 1333MHz FSB 2GB 667MHz (2 X 1MB) Single Ranked Fully Buffered DIMMs 24X IDE CD-RW/DVD ROM Drive 73GB 15K RPM Serial-Attach SCSI 3Gbps 2.5-in Hot Plug Hard Drive Dual 10/100/1000 Ethernet Network Ports 17 Flat LCD Monitor 64 MB Dual Monitor Video Card 1 serial port 1 parallel port 6 USB 2.0 ports Speakers USB Keyboard USB Optical Mouse Surge Suppression Strip

Server Software

Windows 2008/2003 Server Operating System Microsoft SQL Server 2005 Relational Database Management System SYSTEM Server Software for Windows 2008/2003 ID

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 277

SECTION III

WORKSTATION & PERIPHERAL REQUIREMENTS

5. Servers for Windows 2008/2003 Integrated Systems All total security knowledge management system data shall reside on the database server. Also, all database & query processing shall take place at the server. The database server can also be utilized as a workstation with full alarm monitoring, imaging, display, editing, and administrative capabilities. Intelligent System Controllers can also be connected to the database server. The server shall operate on the Windows 2008/2003 Server System platform and utilize Microsoft 2008/2003 Server as its Relational Database Management System. The Server for Windows 2008/2003 Integrated Systems shall consist of the following minimum specifications: PC Specifications

Intel Quad Core Xeon E5410, 2.33GHz, 2x6MB L2 Cache, 1333MHz FSB 2GB 667MHz (2 X 1MB) Single Ranked Fully Buffered DIMMs 24X IDE CD-RW/DVD ROM Drive 73GB 15K RPM Serial-Attach SCSI 3Gbps 2.5-in Hot Plug Hard Drive Dual 10/100/1000 Ethernet Network Ports 17 Flat LCD Monitor 64 MB Dual Monitor Video Card 1 serial port 1 parallel port 6 USB 2.0 ports Speakers USB Keyboard USB Optical Mouse Surge Suppression Strip

Server Software

Microsoft Windows 2008/2003 Server Operating System Microsoft SQL Server 2005 Relational Database Management System SYSTEM Server Software for Windows 2008/2003

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 278

SECTION III

WORKSTATION & PERIPHERAL REQUIREMENTS

6. Servers for Windows 2008/2003 Integrated Systems All total security knowledge management system data shall reside on the database server. Also, all database & query processing shall take place at the server. Intelligent System Controllers can be connected to the database server. The server shall operate on the Windows 2008/2003 Server System platform and utilize Microsoft SQL Server 2005 as the Relational Database Management System. The Database Server for Windows 2008/2003 Access Control & Alarm Monitoring Systems shall consist of the following minimum specifications: PC Specifications

Intel Quad Core Xeon E5410, 2.33GHz, 2x6MB L2 Cache, 1333MHz FSB 2GB 667MHz (2 X 1MB) Single Ranked Fully Buffered DIMMs 24X IDE CD-RW/DVD ROM Drive 73GB 15K RPM Serial-Attach SCSI 3Gbps 2.5-in Hot Plug Hard Drive Dual 10/100/1000 Ethernet Network Ports 17 Flat LCD Monitor 64 MB Dual Monitor Video Card 1 serial port 1 parallel port 6 USB 2.0 ports Speakers USB Keyboard USB Optical Mouse Surge Suppression Strip Microsoft Windows 2008/2003 Server System Microsoft SQL Server 2005 Relational Database Management System SYSTEM Server Software for Windows 2008/2003

Server Software

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 279

SECTION III

WORKSTATION & PERIPHERAL REQUIREMENTS

B. Client Workstations PC Specifications 1. Client Workstations for Windows 2008/2003 SYSTEMS Client workstations shall be provided for all systems requiring additional workstations. The client workstation shall be utilized as a workstation for alarm monitoring, and/or administration, credential management, visitor management, digital video management, and/or asset management capabilities. Intelligent System Controllers can also be connected to the client workstation provided it is operating on the Windows 2008/2003 System. This client workstation shall operate on the Windows 2008/2003. The client workstation for Windows 2008/2003 Systems shall consist of the following minimum specifications: PC Specifications

Intel Pentium 4 Dual Core E2180, 2.0GHz, 1M L2 Cache, 800FSB 1GB non-ECC, 667MHz DDR2 1x1GB (1DIMM) 24X CDRW/DVD Combo Drive 80GB SATA II 3.0Gb/s, 8MB Cache,7200 rpm hard drive 10/100/1000 Ethernet Network Port 1 serial port 1 parallel port 8 USB 2.0 ports 17 Flat LCD Monitor 64 MB Video Card Speakers USB Keyboard USB Optical Mouse Surge Suppression Strip Microsoft Windows XP or Vista Microsoft SQL Server 2005 Client License SYSTEM Client Software for Windows XP or Vista

Software

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 280

SECTION III
C. Client Workstations Types

WORKSTATION & PERIPHERAL REQUIREMENTS

All client workstations listed below shall operate on a workstation as singular functions or in any combination depending on licensing. 1. Administration An administration client workstation shall be provided with full image display capability and shall be configured to perform system configuration and administrative functions. The following major administration tasks shall be included: field hardware setup & configuration, user administration, reporting capabilities, and time zone & access level setup. The administration client workstation shall be the main client workstation for providing the access control and system administration features described in this specification. 2. Alarm Monitoring An alarm monitoring client workstation shall be provided with full image display capability and shall be configured to perform alarm monitoring operations. The following major alarm monitoring tasks shall be included: graphical alarm monitoring via maps and graphical system status trees, acknowledging alarms, performing traces, output control functions, live video user verification, and cardholder record lookup. Where applicable, asset and visitor alarms shall be monitored from these client workstations and digital video players shall be used to view video clips of alarmed areas. The alarm monitoring client workstation shall be the main client workstation for providing the alarm monitoring features described in this specification. 3. Viewing A display client workstation shall be provided with full image display capability and shall be utilized for search and view operations of personnel information stored in the SYSTEM database. No editing functions are available on this client workstation. 4. Editing An editing client workstation shall be provided with full image display capability and shall be utilized for search and view operations of personnel information stored in the SYSTEM database. System Operators shall then be able to edit the cardholders record, with the exception of the cardholders photo. To edit the cardholders photo, the enrollment and badging client workstation must be utilized.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 281

SECTION III
5. Enrollment and Badging

WORKSTATION & PERIPHERAL REQUIREMENTS

An enrollment and badging client workstation shall be an electronic photo ID computer client workstation that shall be used to enroll cardholders, capture photos, and maintain the personnel information and images in the SYSTEM relational database. This information shall be recalled at any time to modify existing records or verify employee status. The enrollment and badging client workstation shall be the primary client workstation for employee enrollment, image capture, and access level assignment to cardholders. 6. Printing A printing client workstation shall be a photo ID client workstation that shall be used to issue or re-issue credentials from records that are maintained and stored in the SYSTEM database. The printing client workstation shall be the primary client workstation for credentials issuance. 7. Asset Management An asset management client workstation shall be configured to perform asset management system configuration and administrative functions. The following major administration tasks shall be included: asset field hardware setup & configuration, user administration, setup of asset types and subtypes, and enrollment of assets. The asset management client workstation shall be the main client workstation for providing the asset management features described in this specification. 8. Digital Video The digital video management client workstation shall be configured to perform digital video system configuration and administration functions. The following major administration tasks shall be included: configuring digital video recorders, configuring video cameras, and configuring camera/device links. The digital video management client workstation shall be the main client workstation for providing the digital video features described in the specification. 9. Intrusion Detection The intrusion detection management client workstation shall be configured to perform intrusion detection system configuration and administration functions. The following major administration tasks shall be included: configuring receiver accounts, configuring receiver areas, and configuring receiver zones. The intrusion detection management client workstation shall be the main client workstation for providing the intrusion detection features described in the specification.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 282

SECTION III
10. Visitor Management

WORKSTATION & PERIPHERAL REQUIREMENTS

The visitor management client workstation shall be used to enroll visitors, schedule visits, and view visitor related reports. The visitor management client workstation shall be the main client workstation for providing the visitor management features described in the specification. 11. Remote Access Level Management The remote access level management client workstation shall be used to remotely manage cardholder access levels. The remote access level management client workstation shall be the main client workstation for providing the remote access level management features described in the specification 12. Integrated An integrated client workstation shall consist of any combination of the above client workstations depending on licensing.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 283

SECTION III
D. Peripherals 1. Video Camera

WORKSTATION & PERIPHERAL REQUIREMENTS

The SYSTEM, when utilizing the credential management module of the SYSTEM, shall utilize a video camera to capture cardholders photos. The video camera shall be highly durable with a built in auto-focus feature. It shall have an auto iris, an optical power zoom lens, and capable of USB connectivity. The video camera shall utilize advanced digital signal processing, have a ten position zoom lens, and output an S-Video signal. The Video Camera shall have the following minimum requirements: Signal Format: Focal Length Aperture Zoom Ratio Zoom Options Filter Size Lens Glass Iris Options Iris Focus Picture Element Resolution Minimum Illumination S/N Ratio AES BLC Neg/Pos Gain Control White Balance Power Source Dimensions DSP Control Housing NTSC 3.9mm ~ 63mm (126mm digital 2X) f1.6 to close 16 X 1 actual Motorized, Remote 46 mm Color Corrected - Zero Aberration Motorized or RS232 Control Auto or Manual Auto Focus or Manual 811 (H) X 494 (V) 470 TV Lines 1 Lux at f1.2 Better than 48db 1/60, 1/10,000 sec. (8 steps) Digital Processor, Auto Negative, Positive AGC 8db~38db Auto: 2,600K-11,000K, Manual 12V DC +/- 10% 62(W) X 62.2(H) X 102.2(D) mm Programmable set up functions RS-232/RS-422 Die Cast Aluminum

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 284

SECTION III
2. Video Capture Board

WORKSTATION & PERIPHERAL REQUIREMENTS

The SYSTEM, when utilizing the credential management module of the SYSTEM software, shall utilize an integrated video capture board. The video capture board shall be used for displaying a live video image onto the enrollment & badging client workstation during the capture process of cardholder enrollment and/or when the SYSTEM is being utilized with the SYSTEMs Live Video User Verification feature. The high performance video capture board shall utilize a PCI slot within the client workstation and be designed to capture and display 24 bit color video images onto the enrollment & badging client workstations. The video board shall accept both Composite and S-Video output signals from compatible cameras and shall offer an integrated SuperVGA display. The Video Capture Board shall have the following minimum requirements: Bus Slot Utilized in PC: Display: Inputs Accepted: Flash Sync Capabilities: Video Formats: Colors Supported: Video Memory: Video Overlay: Approvals:

PCI SVGA Composite and S-Video Yes, integrated on the board NTSC and PAL Up to 16.7 million 2MB DRAM Yes FCC Class B and CE

High-performance PCI or AGP bus frame grabber Integrated 3D graphics accelerator 8 MB SGRAM video frame buffer Display resolution up to 1600 x 1200 High quality video capture and display of NTSC and PAL video Nondestructive color key overlay of graphics on live video Up to 3 composite/RS170 and 1 S-Video inputs High quality composite or S-Video output Progressive-scan camera support YUV 4:2:2 color and 8-bit RS-170 monochrome video digitizing Programmable offset and gain on video input Optically isolated output trigger, strobe interface LENEL - A UTC FIRE & SECURITY COMPANY

OnGuard

Functional Specifications Version 6.3 Series

Page 285

SECTION III

WORKSTATION & PERIPHERAL REQUIREMENTS

General purpose TTL input and output triggers Chromakey for live video graphics underlay Triple Video Buffering support

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 286

SECTION III
3. Direct Card Printer

WORKSTATION & PERIPHERAL REQUIREMENTS

The SYSTEM, when utilizing the credential management module of the SYSTEM software, shall utilize a thermal digital imaging printer which is integrated into the SYSTEM and prints directly onto a PVC card at a minimum rate of 50 cards per hour. It shall print a minimum of 24 bit color at a 300 DPI resolution onto PVC card media and shall be seamlessly integrated to the SYSTEM. The printer shall be able to place 256 color gradations for a total of 16.7 million colors in each dot of the image to ensure photographic quality output. The card media is to be fed to the printer automatically through a card hopper that shall accommodate a minimum of 100 .030 mil thick cards. Manually feeding each card into the printer will not be acceptable. The SYSTEM shall download the badge layout directly to the printer and, using a dye diffusion thermal transfer process, print it onto the card. The dyes are to be embedded into the card, making it difficult to permanently alter its appearance with erasers or pens. The card production system shall apply a clear security over-laminate to the entire printable area of the card. An encoder is to be an integrated part of the digital ID printer. The digital ID printer shall provide magnetic stripe encoding of all credentials utilizing an on-line magnetic stripe encoder device. The magnetic stripe fields shall be sent to the encoder automatically from the SYSTEM based on the cardholder record information. The encoding shall conform to ABA Track II and ANSI specifications. The direct card printer shall be of a desktop style and print full color images, text, graphics, logos, and/or bar-codes directly onto PVC card media. The direct card printer shall use Dye Diffusion Thermal Transfer Technology to produce near photographic quality images. It shall be driven by a 32-bit RISC processor with 4MB of image memory to ensure high speed operation and reliability. The direct card printer shall have the minimum specifications: Thermal Print Head: Print Head Width: Resolution: Image Data: Colors: Print Speed: Processor: Internal Memory: Frame Store: 672 dot wide, thin film 56.9 mm 300 dpi up to 8 bits per color Yellow, Magenta, Cyan, Black, Overlay 8 seconds per color 32-bit RISC processor 4MB 948 x 672 pixels 24 bit color

Image Position on Media: better than 0.015

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 287

SECTION III
Cooling Mechanism: Input Range: Frequency: Load: Approvals: Media: Material: Thickness: Cassette Capacity: Magnetic Encoder: Operating Temperature: Storage Temperature:

WORKSTATION & PERIPHERAL REQUIREMENTS

Integral Fan, Air exhausted from the rear of the printer 90-125 VAC, 180-265 VAC 47-63 Hz 200 Watts Max UL, CSA, TUV CR-80 credit card size, 2.125 x 3.375 Gloss PVC Surface 0.015 - 0.063 100 to 500 cards On-line encoding of Track 1, 2, and 3, hi-coercivity (4,000 Oersteds) 5 to 40 degrees Celsius -20 to +85 degrees Celsius

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 288

SECTION III
4. Signature Capture Tablet

WORKSTATION & PERIPHERAL REQUIREMENTS

The SYSTEM shall support a graphics signature tablet when the signature feature is being utilized. The signature tablet shall be small in size, intuitive, and responsive. The pen for the tablet shall be cordless and not require any batteries for operation. The signature capture tablet shall have the minimum specifications: Resolution: Accuracy (overall with pen): Pressure Levels: Maximum reading height: Maximum Report Rate: Origin Position: Communications Interface: Connector: Operating Temperature: 2540 lpi/ 100 lpmm +/- 0.5 mm (+/- .02 in.), maximum 256 Levels 5 mm (+/- .2 in.) or less 205 points per second Upper left

RS-232C 9-Pin, D-sub, female 5 degrees to 40 degrees Celsius (41 degrees- 104 degrees Fahrenheit) Storage Temperature: -10 degrees to 60 degrees Celsius (14 degrees to 140 degrees Fahrenheit) Operating Relative Humidity: 20% to 80% Storage Relative Humidity: 90% or less Certifications: FCC class B, VCCI class 2, TUV-RFI Active Area (W x D): Physical Size (W x D x H): Cable Length: Power Consumption: Weight: Power Supply: Input Current: 5.04 x 3.78 inches 7.52 x 6.89 x 0.27 inches 6.5 Feet 1.2 Watt 1 pound DC 12V, 200 mA 100 mA

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 289

SECTION III
5. Report Printer

WORKSTATION & PERIPHERAL REQUIREMENTS

The laser text printer shall be a parallel interface laser process printer, printing four (4) pages per minute with 300 dpi resolution. The printer shall employ 1 MB memory, a 100sheet capacity and a microfine toner cartridge provided to produce quality black and white reports. The report printer shall have the minimum specifications: Resolution: Resolution Technology: Print Speed: Languages: Memory: Memory Technology: Media Capacity: Media Sizes: Media Types: Scalable Typefaces: Interfaces: Warranty: Dimensions: Weight: 300 dpi Resolution Enhancement Technology and Microfine Toner 4 pages per minute Enhanced HP PCL 5 Standard: 1 MB Maximum: 2 MB Memory Enhancement Technology 100 sheets input, 50 sheets output Letter, Legal, A4, Executive Plain and Recyclable Papers, transparencies, and labels 16-28 lb. Sheets 26 Intellifont Standard: HP Bi-Tronics Parallel Optional: HP JetDirect EX One Year 14.5 x 14.0 x 6.2 15.5 pounds

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 290

SECTION III
6. Event Printer

WORKSTATION & PERIPHERAL REQUIREMENTS

The event printer shall be a compact serial 9 pin dot matrix printer which will print text data in draft and NLQ modes. The printer shall be capable of 9600 baud communications speed, 12 CPI and less than 55db in quiet mode. Optionally, a parallel port interface shall be used. The printer shall notify the System Operator when paper supply has been depleted. The event printer shall have the minimum specifications: Print head type: Print head width: Super Speed Draft: Near Letter Quality: Resident Scalable Fonts: Okidata Standard Emulation: Automatic Paper Loading: Interface: Memory (Buffer) Size: Noise Level Quiet Mode: Warranty: Dimensions: Weight: 9 Pin .34 mm 435 CPS (12 CPI) 75 CPS (10 CPI) 2 NLQ Yes Yes Parallel 28K 55 db One year 15.7 x 13.6 x 4.6 15.4 pounds

Noise Level Operating mode: 57 db

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 291

SECTION III
7. Modem

WORKSTATION & PERIPHERAL REQUIREMENTS

The SYSTEM modem shall be available for remote diagnostics, downloading of upgrades, dial-in capabilities, and remote communications. The modem shall be plug and play and support the Windows 2008/2003 Operating System. All SYSTEM servers must include a modem. The modem shall have the minimum specifications: Data Transmission: Universal Compatibility: Error Control: Data Compression: Approvals: 56 Kbps Yes V.42/MNP 2-4 error control V.42 bis/MNP5 data compression FCC Approved (Part 15 Class B/Part 68) IC (Formerly DOC) Approved UL Listed CSA Approved Warranty: 5 year limited

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 292

SECTION III
8. Tape Backup System

WORKSTATION & PERIPHERAL REQUIREMENTS

The SYSTEM server MUST utilize a tape backup system for SYSTEM backups and archiving capabilities. The tape backup system must support the Windows 2008/2003 Operating System. The tape backup system shall be a true 32-bit client/server data storage and management system. It shall offer advanced features such as centralized administration and monitoring, remote administration, unattended scheduled backup and shall provide a wide range of data protection services. The tape backup system shall have the minimum specifications: Centralized Administration: Shall allow System Administrators to administer one or more servers from a single Windows 2008/2003 workstation. Shall allow System Administrators to administer one or more servers from remote locations. Shall allow System Administrators to backup Microsoft SQL Server databases. These are the main files that shall be backed up. Allows System Administrators to perform backups at pre-determined times. Intervals shall be in hourly, daily, weekly, and monthly intervals.

Remote Access Server Support: SQL Server Support:

Scheduled/Unattended Backups:

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 293

SECTION IV
ACCESS CONTROL FIELD HARDWARE

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

Section IV - ACCESS CONTROL FIELD HARDWARE DEVICES

A. Overview The Total Security Knowledge Management System shall be equipped with the access control field hardware required to receive alarms and administer all access granted/denied decisions. All field hardware must be designed to meet UL 294 and ULC requirements. The Total Security Knowledge Management System must be able to retrieve device serial numbers from all field hardware, excluding card readers, biometric readers, and keypads. Depending upon the configuration, the Total Security Knowledge Management System field hardware must be able to include any or all of the following components: 1) Intelligent System Controller (ISC) 2) Input Control Module (ICM) 3) Output Control Module (OCM) 4) Card Readers 5) Single Reader Interface Module (SRI) 6) Dual Reader Interface Module (DRI) 7) Biometric Reader Interface Module 8) Proximity Card Readers 9) Open Card Readers 10) Access Control Network Door Controllers or Network Controller/Readers 11) Panel Power Supplies 12) Star Configuration Splitters

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 295

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

1. Intelligent System Controller (ISC) Note: All references to the ISC in other sections of this document are equally applicable to the Intelligent Dual Reader Controller (IDRC) except as described in the IDRC section. Note also that while the ISC supports automatic switching between dual communications paths, the IDRC does not. An Intelligent System Controller (ISC) shall link the Total Security Knowledge Management Solutions Software to all other field hardware components (Card Readers and Input Control Modules). The ISC shall provide full distributed processing of access control & alarm monitoring operations. Access levels, hardware configurations, and programmed alarm outputs assigned at the administration client workstation shall be downloaded to the ISC, which shall store this information and function using its high speed, local 32-bit microprocessor. All access granted/denied decisions must be made at the ISC to provide fast responses to card reader transactions. A fully configured ISC with 64 card readers shall require less than one-half (0.5) seconds to grant access to an authorized cardholder or deny access to an unauthorized cardholder. The SYSTEM Access Control Field Hardware shall provide a network based ISC. The network ISC shall be a 10/100 MB Ethernet based panel that has the capability to reside on a local area network (LAN) or wide area network (WAN) without connectivity to a PC serial port. The ISC shall utilize an onboard Ethernet capability deliver this functionality without the need for additional components within the system. Network based Intelligent System Controllers shall be able to communicate back with the database server through industry standard switches and routers and shall not have to be on the same subnet. The ISC is required to continue to function normally (stand-alone) in the event that it loses communication with the SYSTEM software. While in this off-line state, the ISC is required to make access granted/denied decisions and maintain a log of the events that have occurred. Events shall be stored in local memory, and then uploaded automatically to the SYSTEM database after communication has been restored. The ISC shall contain an embedded web server to allow configuration of network and communication parameters. For security, this web server must support SSL communications and allow usernames and passwords to be defined and changed. The ISC must contain the following features: UL 294, ULC, and CE Certified Support for Host Communications Speed of 115,200 bps Support for Direct Connect, Remote Dial Up, or Local Area Network (LAN) Connection

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 296

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

Support for Dual Path Host Communications - Secondary Path shall be either Direct Connect, Local Area Network (LAN) Connection, or Remote Dial Up Connection. Support for up to 15 MB of On-Board Memory LAN Support shall utilize an RJ45 (10/100baseT) Ethernet Interface Remotely reprogrammable Flash Memory for real time program updates and overall host communications Support for two 2-wire downstream RS-485 ports Storage of up to 450,000 cardholders/50,000 events within the onboard nonvolatile memory. ISC configuration and cardholder database download from the SYSTEM shall require no more than ten (10) minutes for serial connection, or 5 minutes for LAN connection. Downstream ports shall be for connecting card readers and data gathering panels via RS-485 multi-drop wiring configuration Support for up to 64 devices consisting of Reader Interface Modules, Input Control Modules, and Output Control Modules in any combination desired with a maximum of 32 ICMs per ISC Support of multiple card technologies Supervised Communications between ISC and SYSTEM Software Multi drop support for up to eight ISCs per SYSTEM communications port Support of up to eight card formats and facility codes RS-485 Full Duplex, UL 1076 Grade AA communication channel to the SYSTEM head-end Integration to other manufacturers card readers Uninterruptible Power Supply (UPS) with battery backup 32-bit Microprocessor Biometric Interface Support An ISC downstream serial port shall multi-drop up to 32 access control field hardware devices using an RS-485 UL 1076 Grade A communication format allowing a distance of 4,000 feet using Belden 9842 cable or equivalent 12 VDC or 24 VDC input power Issue Code Support for both Magnetic and Wiegand Card Formats Individual Shunt Times (ADA Requirement)

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 297

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

Up to Nine Digit PIN Codes Status LEDs for normal component and communication status

2. Intelligent Dual Reader Controller (IDRC) Note: All references to Intelligent System Controller (ISC) in other sections of this document are equally applicable to the IDRC except as described below. Note also that the IDRC does not support automatic switching between dual communications paths. An Intelligent Dual System Controller (IDRC) shall link the Total Security Knowledge Management Solutions Software to all other field hardware components (Card Readers and Input Control Modules). The IDRC shall provide full processing of access control & alarm monitoring operations. Access levels, hardware configurations, and programmed alarm outputs assigned at the administration client workstation shall be downloaded to the IDRC, which shall store this information and function using its high speed, local 32bit microprocessor. All access granted/denied decisions must be made at the IDRC to provide fast responses to card reader transactions. A fully configured IDRC with 64 card readers shall require less than one-half (0.5) seconds to grant access to an authorized cardholder or deny access to an unauthorized cardholder. The IDRC shall provide full onboard control for 2 card readers and 2 doors. Card readers shall be interfaced directly to the IDRC with no additional components required. The IDRC shall provide status inputs for door position sensors and request-to-exit devices for each of the two doors. The IDRC shall also provide a strike output relay and a programmable auxiliary output relay for each of the two doors. Either or both ports on the IDRC must support the connection of a biometric fingerprint reader device utilizing server-based templates. The biometric fingerprint reader device can be used in lieu of or in conjunction with a card reader to provide enhanced security and convenience. When a biometric fingerprint reader device is connected to the IDRC, the IDRC shall provide biometric templates to the device directly, without the requirement for a separate biometric gateway device. The SYSTEM Access Control Field Hardware shall provide a network based IDRC. The network IDRC shall be a 10/100 MB Ethernet based panel that has the capability to reside on a local area network (LAN) or wide area network (WAN) without connectivity to a PC serial port. The IDRC shall utilize integrated Ethernet communications to deliver this functionality. Network based Intelligent System Controllers shall be able to communicate back with the database server through industry standard switches and routers and shall not have to be on the same subnet. The IDRC is required to continue to function normally (stand-alone) in the event that it loses communication with the SYSTEM software. While in this off-line state, the IDRC is required to make access granted/denied decisions and maintain a log of the events that have occurred. Events shall be stored in local memory, and then uploaded automatically to the SYSTEM database after communication has been restored.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 298

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

The IDRC shall contain an embedded web server to allow configuration of network and communication parameters. For security, this web server must support SSL communications and allow usernames and passwords to be defined and changed.

The IDRC must contain the following features: UL 294, ULC, and CE Certified Support for RS232 Host Communications Speed of 115,200 bps Support for Direct Connect, Remote Dial Up, or Local Area Network (LAN) Connection At least 6 MB of available On-Board non-Volatile FLASH Memory for storage of configuration and cardholder data LAN Support shall utilize on-board RJ45 (10/100baseT) Ethernet Interface Remotely updateable Flash Memory storage of operating program for real time program updates and overall host communications Support for up to 32 downstream devices connected via a 2-wire RS-485 link Standard on-board memory storage for up to 275,000 cardholders/50,000 events IDRC configuration and cardholder database download from the SYSTEM shall require no more than ten (10) minutes for serial connection, or 5 minutes for LAN connection. Downstream ports shall be for connecting card readers and data gathering panels via RS-485 multi-drop wiring configuration Support for up to 32 devices consisting of Reader Interface Modules, Input Control Modules, and Output Control Modules in any combination desired with a maximum of 16 ICMs per IDRC Support of multiple card technologies Supervised Communications between IDRC and SYSTEM Software Support of up to eight card formats and facility codes Integration to other manufacturers card readers Uninterruptible Power Supply (UPS) with battery backup 32-bit Microprocessor Biometric Interface Support

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 299

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

An IDRC downstream serial port shall multi-drop 32 access control field hardware devices using an RS-485 UL 1076 Grade A communication format allowing a distance of 4,000 feet using Belden 9842 cable or equivalent 12 VDC or 24 VDC input power Issue Code Support for both Magnetic and Wiegand Card Formats Individual Shunt Times (ADA Requirement) Up to Nine Digit PIN Codes Status LEDs for normal component and communication status

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 300

SECTION IV
2. Input Control Module (ICM)

ACCESS CONTROL FIELD HARDWARE DEVICES

The Input Control Module shall monitor all system alarm inputs. Grade B Inputs The Input Control Module shall provide up to 16 UL 1076 Grade B analog unsupervised alarm input zones to monitor and report alarm conditions, power faults, and tampers as well as 2 output control relays. When an alarm input is activated, the associated alarm condition shall be reported to both the ISC and subsequently to the SYSTEM alarm monitoring client workstation. Status LEDs shall provide information about the sixteen alarm zone inputs, cabinet tamper, and power fault. For each status LED, a slow flash shall imply a "No Alarm" condition and a fast flash shall indicate an alarm condition. Grade A Inputs The Input Control Module shall provide up to 16 UL 1076 Grade A analog supervised alarm input zones to monitor and report line fault conditions (open, short, ground, or circuit fault), alarm conditions, power faults and tampers. When an alarm input is activated, the associated alarm condition shall be reported to both the ISC and subsequently to the SYSTEM alarm monitoring client workstation. Status LEDs shall provide information about the sixteen alarm zone inputs, cabinet tamper, and power fault. For each status LED, a slow flash shall imply a "No Alarm" condition, a fast flash shall indicate an Alarm Condition, and a solid LED shall indicate a Zone Fault (open, short, ground, or circuit fault). Grade AA Inputs The Input Control Module must provide up to 16 UL 1076 Grade AA alarm input zones to monitor and report line fault conditions, alarm conditions, power faults and tampers. When an alarm input is activated, the associated alarm condition shall be reported to the ISC and subsequently to a SYSTEM alarm monitoring client workstation. Status LEDs shall provide information about the sixteen alarm zone inputs, cabinet tamper, and power fault. For each status LED, a slow flash shall imply a "No Alarm" condition, a fast flash shall indicate an Alarm Condition, and a steady LED shall indicate a Circuit Fault (open, short, ground). The Input Control Modules must also be able to operate independently and in conjunction with Output Control Modules (OCM), which will send an output LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 301

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

signal to a corresponding output device upon alarm input activation. Once an alarm has been received, the Input Control Module shall activate any or all alarm outputs within the Output Control Module. The Output Control Module shall provide 16 Form C outputs rated at 5A @ 30VDC. Upon an alarm input from the Input Control Module, the Output Control Module shall transmit an activating signal to a corresponding output device. Up to 32 ICMs shall be connected to an available ISC using RS-485 cabling. Diagnostic LEDs shall indicate ISC communication, input zone scanning, and Input Control Module heartbeat. The ICM must contain the following features: UL 294, ULC, and CE Certified Alarm contact status scanning at up to 180 times per second for each zone Eight configuration DIP switches to assign unit addresses and communications speed A low power CMOS microprocessor Filtered data for noise rejection to prevent false alarms Up to 16 Grade B, A, or AA Supervised Inputs in any Combination 12 VDC or 24 VDC Input Power 2 Form C Contacts for load switching 2 dedicated inputs for tamper and power status

3. Output Control Module (OCM) The Output Control Module shall incorporate 16 Output Relays that are capable of controlling a corresponding output device upon any input activation or on command from the SYSTEM. Output relays shall be capable of responding to: Input alarms from a within the same ISC. Commands from a System Operator. Time zone control commands for automatic operation.

Output relays shall be capable of: Pulsing for a predetermined duration. Duration shall be programmable for each relay individually. "Following" any input point an ICM attached to the same ISC (on with alarm, off when clear, or as required). LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 302

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

Responding on command from the System Operator to pulse, command on, command off, or reset to normal state.

Each OCM shall provide 16 Form C relays rated at 5A @ 30 VDC. The OCM shall control the relays by digital communication. Upon an input from the ICM or command from the System Operator, the ICM shall transmit an activating signal to a corresponding relay. The OCM shall be UL 294 and CE Certified. 4. Card Readers The SYSTEM shall support a variety of card readers that must encompass a wide functional range. The SYSTEM may combine any of the card readers described below for installations requiring multiple types of card reader capability (i.e., card only, card and/or PIN, supervised inputs, etc.). These card readers, described below, shall be available in Magnetic Stripe and Wiegand output format, depending on the card reader. All magnetic stripe card readers are to be housed in an aluminum bezel with a wide leadin for easy card entry. Each card reader shall contain read head electronics, a micro ISC, and a sender to encode digital door control signals. A bi-color LED (s) (red and green) shall be used to indicate card reader status and access status. A flashing red LED shall indicate the card reader is waiting for a card to be entered. A solid red LED is to indicate that the card reader has defaulted to a locked mode of operation. A solid green LED shall indicate the card reader has defaulted to an unlocked mode of operation. The green LED must illuminate upon a valid credential swipe/PIN entry for the duration of the door strike time. Card Readers must be able to support a user defined downloadable off-line mode of operation (locked, unlocked, or facility code), which will go in effect during loss of communication with the ISC. All card readers shall provide audible feedback to indicate access granted/denied decisions. Upon a card swipe, two beeps shall indicate access granted and three beeps shall indicate access denied. All keypad buttons shall provide tactile audible feedback. As many as 32 card readers of any type described below shall be able to be connected to a single ISC port. All card readers may optionally include card reader back boxes for conduit installations. a) Standard Card Readers with Wiegand Communications and Clock/Data Output The standard card readers with Wiegand Communications and Clock/Data Output shall be provided with or without a keypad. These card readers with a keypad shall include a 12 character, raised membrane tactile keypad with audio feedback, enabling PINs to be used in conjunction with cards.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 303

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

The standard card reader with Wiegand Communications and Clock/Data Output must offer the following features: UL 294, ULC, and CE Certified Low Power/Surface Mount Card Reader 600,000 pass read head Small, rugged, die cast aluminum Bi-directional card swipe Weatherized Finishes LEDs for access and card reader status Card and PIN data shares same output lines 12VDC or 5VDC Input Power RJ-45 Jack for Quick Installation

5. Single Reader Interface Module (SRI) The Single Reader Interface Module shall provide an interface between the ISC and card readers. The Single Reader Interface Module must operate with any card reader that produces a standard Wiegand (Data 1/Data 0 or Clock and Data) communication output, and F/2F interface, or that offers supervised communications using Open Supervised Device Protocol (OSDP). As with other card reader types listed above, a single ISC shall be able to multi-drop as many as 32 Single Reader Interface Modules. The SRI must support the connection of a biometric fingerprint reader device utilizing server-based templates. The biometric fingerprint reader device can be used in lieu of or in conjunction with a card reader to provide enhanced security and convenience. When a biometric fingerprint reader device is connected to the SRI, the SRI shall provide biometric templates to the device directly from the ISC or IDRC without the requirement for a separate biometric gateway device. The SRI shall monitor on a per door basis door position and request-to-exit device status. It shall also control the electric strike and provide an auxiliary relay output. The SRI shall support up to eight unique card formats. The SRI shall support an integrated card reader/keypad and shall support three access modes upon loss of communication with the ISC; locked, unlocked, and facility code. The SRI shall offer the following features:
1. 2.

UL 294, ULC, and CE Certified 12VDC Power

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 304

SECTION IV
3. 4.

ACCESS CONTROL FIELD HARDWARE DEVICES

Support for up to eight Magnetic and Wiegand Card formats Support for Clock/Data, Data1/Data0 Wiegand, F/2F, and Open Supervised Device Protocol (OSDP) Communications 1 Programmable Relay Output Per SRI

5.

6. Dual Reader Interface Module (DRI) The Dual Reader Interface Module shall provide an interface between the ISC and card readers. The Dual Reader Interface Module must operate with any card reader that produces a standard Wiegand (Data 1/Data 0 or Clock and Data) communication output, an F/2F interface, or that offers supervised communications using Open Supervised Device Protocol (OSDP). As with other card reader types listed above, a single ISC shall be able to multi-drop as many as 32 Dual Reader Interface Modules. Each DRI shall support two card readers, each of which shall be up to 500 away from the DRI. Either or both ports on the DRI must support the connection of a biometric fingerprint reader device utilizing server-based templates. The biometric fingerprint reader device can be used in lieu of or in conjunction with a card reader to provide enhanced security and convenience. When a biometric fingerprint reader device is connected to the DRI, the DRI shall provide biometric templates to the device directly from the ISC or IDRC without the requirement for a separate biometric gateway device. The DRI shall monitor door position and request-to-exit device status for each of two doors, and monitor a total of 4 auxiliary alarm inputs per DRI. It shall also control the electric strike for each of two doors and provide a total of four auxiliary relay outputs per DRI. The DRI shall support up to eight unique card formats. The DRI shall support an integrated card reader/keypad and shall support three access modes upon loss of communication with the ISC; locked, unlocked, and facility code. The DRI shall offer the following features:
1. 2. 3. 4.

UL 294, ULC, and CE Certified 12VDC or 24VDC Input Power Support for up to eight Magnetic and Wiegand Card formats Support for Clock/Data, Data1/Data0 Wiegand, F/2F, and Open Supervised Device Protocol (OSDP) Communications 2 Programmable Inputs and 2 Programmable Relay Outputs per Reader

5.

7. Biometric Reader Interface (BRI) The Biometric Reader Interface Module shall provide an interface between a designated ISC and biometric readers. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 305

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

One (1) BRI may be connected to each downstream port on the ISC, which means that a maximum of four Biometric Reader Interface Modules shall be supported on one ISC. The BRI shall have the capability to monitor on a per door basis, door position, exit push button, and two auxiliary alarm inputs. It shall also control the electric strike and provide one auxiliary relay output. The BRI shall support three access modes upon loss of communication with the ISC; locked, unlocked, and facility code. The BRI shall offer the following features: 1. 12VDC or 12VAC Power 2. Support for up to eight Magnetic and Wiegand Card formats 3. Support for RS-485 biometric reader protocol communications 4. One Programmable Relay Output Per Reader 8. Proximity Card Readers a) LenelProx Proximity Card Readers The SYSTEM shall provide the ability to support LenelProx Proximity Card Readers or an approved equal. This product line shall offer a variety of card readers to match CUSTOMER needs. Each card reader shall offer a low profile, rugged, weatherized polycarbonate sealed enclosure with multi-color LEDs and a sounder for access granted and denied indications. Each shall be mountable indoor or outdoor. 1) The LenelProx Special Range Reader shall have a Wiegand Output with a 4 to 5.5 inch Read Range. The reader shall be metal compensated that is designed to be mullion mounted either indoors or outdoors. 2) The LenelProx Mullion Mount Reader shall have a Wiegand and RS-232 simultaneous output with a 6 to 8 inch read range. The reader shall be metal compensated that is designed to be mullion mounted either indoors or outdoors. 3) The LenelProx Switch Plate Reader shall have a Wiegand and RS-232 simultaneous output with a 6 to 8 inch read range. The reader shall be designed to mount on a single gang electrical box either indoors or outdoors. 4) The LenelProx Keypad Reader shall have an integrated keypad with 8 bit burst output and simultaneous Wiegand and RS-232 outputs for card only with a 6 to 8 inch read range. The reader shall be designed to mount either indoors or outdoors.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 306

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

5) LenelProx Mid Range Reader shall have Wiegand and RS-232 simultaneous outputs with a 18 to 24 inch read range. The reader shall be designed for both indoor and outdoor applications with optional metal compensation. 6) LenelProx Long Range 900Mhz Reader shall have Wiegand and RS-232 simultaneous outputs with a 9 to 11 foot read range. The reader shall be designed for parking lot gate applications and only works with high frequency tags LenelProx-windshield and LenelProx metal mount tags.

9. Open Card Readers a) Lenel OpenCard Readers The SYSTEM shall provide the ability to support Lenel OpenCard readers. The open card reader shall have all of the features and functionality of the LenelProx proximity reader described in section IV part 8. In addition, the open card reader shall allow many different card formats to be verified by a single reader. The open card reader must be able to provide access control cardholder verification with the following card formats: 1. GE CASI proxLIte, 2. HID proximity 3. LenelProx Proximity 4. AWID Proximity 5. Lenel OpenCard DESFire 6. XceedID ISO-X 7. OES (Open Encoding Standard) for MIFARE 8. XceedID Secure Mifare 9. HID iCLASS (card serial number) 10. DESFIRE (card serial number[instead of Lenel OpenCard DESFire]) 11. MIFARE (card serial number[instead of secure MIFARE formats]) 12. PIV end point dual interface smart card FASC-N (must order PIV Version)

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 307

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

10. Access Control Network Door Controllers or Network Controller/Readers a) Single door network door controller The SYSTEM shall support a single door network door controller. The network door controller shall provide access control processing, host functionality and power for a single door, including reader, lock, door status, request-to-exit device, and auxiliary sounder. The network door controller shall accept Wiegand output card readers and card formats up to 128 bits in length. The network door controller shall support eight (8) access levels per badge per device. The SYSTEM shall provide a warning when attempting to add more than eight (8) access levels with a common network door controller to a cardholder badge, to bulk badges, or to selected groups. The network door controller shall provide a complete, fully featured access control hardware and firmware infrastructure for host-based access control software applications. The network door controller shall communicate with hosted access control software using TCP/IP protocol over Ethernet. The network door controller shall have the capability to be powered either by PoE (Power over Ethernet) or by an external supply. When powered by PoE, the network door controller shall provide 12VDC power to a connected reader, and optionally to a 12VDC powered door locking mechanism, up to the current limit listed in the specifications below. The network door controller shall provide full distributed processing of all access control functions. The unit shall provide fully functional off line operation when not actively communicating with the host access control software application; performing all access decisions and event logging. Upon connection with the host access control software application, the network door controller or network controller/reader shall upload all buffered off-line transactions (minimum of 5,000) to the host software. The network door controller shall incorporate a 32-bit 100 MHz RISC processor running the Linux operating system. The unit shall include a Windows DLL, and the direct-communication OPIN API for integration to host-based access control applications. The network door controller shall provide diagnostics and network connection configuration operations through connection to a local laptop computer. The network door controller shall provide on-board Flash memory to allow program updates to be downloaded directly via the network. The network door controller or network controller/reader shall provide the following minimum memory: 1. 8 MB on-board Flash memory 2. 32 MB SDRAM 3. 256k SRAM LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 308

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

The network door controller shall provide the following certifications: 1. UL 294 Listed Access Control System Units. (The EDGEPlus 82000B has UL294 listing when installed with either the HID 6120B iClass R40 or 6125B iClass RP40 reader). 2. CSA 205 (Canada) 3. FCC Class A Verification 4. EMC for Canada, EU (CE Mark), Australia (C-Tick Mark), New Zealand, Japan 5. EN 50130-4 Access Control Systems Immunity for the EU (CE Mark) The network door controller shall meet the following physical specifications: 1. Dimensions: 3.3 W x 4.8 H x 1.5 D (83.8 mm x 121.9 mm x 36.3 mm) 2. Weight: 6.8 oz (.195 kg) 3. Cover Material: UL94 Polycarbonate 4. Power Requirements 250-1000 mA @ 12 VDC provided either through: a. 12 16 VDC linear Power Supply b. 802.3af compliant Power Over Ethernet (POE) device 5. Temperature: 32 to 122 F (0 to 50 C) 6. Humidity: 5% to 95% relative, non-condensing 7. Visual Indicators: a. System Activity LED b. Network Activity LED 8. Communication ports and connectors: a. RJ-45 connector for Ethernet TCP/IP (10/100baseT) b. Wiegand/Clock-and-Data reader data port 9. Door position. 10. Request to exit (REX) input. 11. Non-latching configurable door lock output relay LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 309

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

12. Unpowered (Dry) contact rated 2A @ 30VDC 13. Powered (Wet) contact rated for up to 600mA @ 12VDC Note: The 600 mA is shared between two relays 14. Non-latching alarm annunciation output relay 15. Unpowered (Dry) contact rated 2A @ 30VDC 16. Powered (Wet) contact rated for up to 600mA @ 12VDC 17. Note: The 600 mA is shared between two relays 18. 12VDC Power input (if not PoE powered) 19. Tamper input (Can have a built-in additional external tamper) 20. AC Power Fail input 21. Battery fail input 22. Cable Distances: a. TCP/IP: 328 feet (100m) using CAT 5 cable b. Wiegand: 500 feet using 9-conductor stranded, overall shield 22 AWG cable (Alpha 1299C) c. Input circuits: 500 feet using 2-conductor shielded 22AWG cable (Alpha 1292C) or 18AWG cable (Alpha 2421C) d. Output circuits: 500 feet using 2-conductor 22AWG cable (Alpha 1172C) or 18AWG cable (Alpha 1897C)

b) Single door network controller/reader The SYSTEM shall support a single door network controller/reader. The network controller/reader shall provide access control processing, host functionality and power for a single door, including lock, door status, request-to-exit device, and auxiliary sounder. The network controller/reader shall support eight (8) access levels per badge per device. The SYSTEM shall provide a warning when attempting to add more than eight (8) access levels with a common network controller/reader to a cardholder badge, to bulk badges, or to selected groups. The network controller/reader shall be of single piece design with integrated card reader as follows: i. iCLASS 13.56 MHz contactless smart card reader. LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 310

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

1. The reader shall encrypt all RF data transmission between the smart card and reader using industry standard encryption techniques and advanced key management. 2. The reader shall be compatible with ISO 15693 read only; 2k bit (256 Byte), 16k bit (2k Byte) and 32k bit (4k Byte); ISO 14443A read only; MIFARE and DESFire (serial number). ISO 14443B read only; 2k bit (256 Byte) and 16k bit (2K Byte). FeliCa IDm ii. MultiCLASS 13.56 MHz contactless and 125kHz Proximity card reader. 1. The reader shall support all HID Proximity formats, including Corporate 1000. 2. The reader shall encrypt all 13.56MHz RF data transmission between the smart card and reader using industry standard encryption techniques and advanced key management. 3. The reader shall be compatible with ISO 15693 read only; 2k bit (256 Byte), 16k bit (2k Byte) and 32k bit (4k Byte); ISO 14443A read only; MIFARE and DESFire (serial number). ISO 14443B read only; 2k bit (256 Byte) and 16k bit (2K Byte). FeliCa IDm. The network controller/reader shall provide a complete, fully featured access control hardware and firmware infrastructure for host-based access control software applications. The network controller/reader shall communicate with hosted access control software using TCP/IP protocol over Ethernet. The network controller/reader shall have the capability to be powered either by PoE (Power over Ethernet) or by an external supply. When powered by PoE, the network door controller shall optionally provide power to a 12VDC door locking mechanism, up to the current limit listed in the specifications below. The network controller/reader shall provide full distributed processing of all access control functions. The unit shall provide fully functional off line operation when not actively communicating with the host access control software application; performing all access decisions and event logging. Upon connection with the host access control software application, the network door controller or network controller/reader shall upload all buffered off-line transactions (minimum of 5,000) to the host software. The network controller/reader shall incorporate a 32-bit 100 MHz RISC processor running the Linux operating system. The unit shall include a Windows DLL, and the direct-communication OPIN API for integration to host-based access control applications. The network controller/reader shall provide diagnostics and network connection configuration operations through connection to a local laptop computer.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 311

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

The network controller/reader shall provide on-board Flash memory to allow program updates to be downloaded directly via the network. The network door controller or network controller/reader shall provide the following minimum memory: 8 MB on-board Flash memory 32 MB SDRAM 256k SRAM

The network door controller or network controller/reader shall provide the following certifications: a. UL 294 Listed Access Control System Units. (Use EDGE Reader 82120B and 82125B in UL installations where exposure is controlled to only authorized persons). b. CSA 205 (Canada) c. FCC Class A Verification d. EMC for Canada, EU (CE Mark), Australia (C-Tick Mark), New Zealand, Japan e. EN 50130-4 Access Control Systems Immunity for the EU (CE Mark) The network controller/reader shall meet the following physical specifications: a. Dimensions: 3.3 W x 4.8 H x 2.3 D (83.8 mm x 121.9 mm x 57.9 mm) b. Weight: Controller/reader - 14.7 oz (.400 kg) c. Cover Material: UL94 Polycarbonate d. Power Requirements: 250-1000 mA @ 12 VDC provided either through: i. 12 16 VDC linear Power Supply ii. 802.3af compliant Power Over Ethernet (POE) device e. Temperature: 32 to 122 F (0 to 50 C) f. Humidity: 5% to 95% relative, non-condensing g. Visual Indicators: i. System Activity LED ii. Network Activity LED iii. Red/Green LEDs indicating access grant/deny h. Communication ports and connectors: i. RJ-45 connector for Ethernet TCP/IP (10/100baseT) ii. Door position input. iii. Request to Exit (REX). iv. Non-latching configurable door lock output relay 1. Unpowered (Dry) contact rated 2A @ 30VDC

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 312

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

2. Powered (Wet) contact rated for up to 600mA @ 12VDC Note: The 600 mA is shared between two relays. v. Non-latching alarm annunciation output relay 1. Unpowered (Dry) contact rated 2A @ 30VDC 2. Powered (Wet) contact rated for up to 600mA @ 12VDC Note: The 600 mA is shared between two relays. vi. 12VDC Power input (when not powered by PoE) vii. Tamper input (Can have a built-in additional external tamper) viii. AC Power Fail input (Can be configured for general purpose use) ix. Battery fail input (Can be configured for general purpose use) i. Cable Distances: a. TCP/IP: 328 feet (100m) using CAT 5 cable b. Input circuits: 500 feet using 2-conductor shielded 22AWG cable (Alpha 1292C) or 18AWG cable (Alpha 2421C) c. Output circuits: 500 feet using 2-conductor 22AWG cable (Alpha 1172C) or 18AWG cable (Alpha 1897C)

11. Field Hardware Power Supplies Power Supplies for field hardware shall be designed specifically for the SYSTEM equipment installed. These power supplies shall be regulated, isolated versions for the ISC, ICM, Card Readers and other equipment. Each version shall be available in UPS with battery back-up and non-UPS models. All power supplies shall be housed in locked enclosures that also allow mounting space for the ISC, ICM, SRI, DRI or other device/panel required. 12. Star Configuration Splitter The SYSTEM shall support a star configuration splitter that shall expand a single ISC communications port into eight 2 wire or four 4 wire RS-485 communications ports to be used in a star configuration. All outgoing data shall be broadcast on all eight ports.

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 313

SECTION IV

ACCESS CONTROL FIELD HARDWARE DEVICES

1212 Pittsford-Victor Road Pittsford, New York 14534

Phone: 585.248.9720 Fax: 585.248.9185

LENEL - A UTC FIRE & SECURITY COMPANY OnGuard Functional Specifications Version 6.3 Series Page 314