Docstoc

Section II - FUNCTIONAL _ OPERATIONAL REQUIREMENTS

Document Sample
Section II - FUNCTIONAL _ OPERATIONAL REQUIREMENTS Powered By Docstoc
					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.        SYSTEM OVERVIEW.......................................................................................................2
  1.      Access Control ...............................................................................................................3
  2.      Alarm Monitoring ..........................................................................................................3
  3.      Credential Management.................................................................................................4
  4.      Digital Video Management ............................................................................................5
  5.      Intrusion Detection Management ..................................................................................5
  6.      Asset Management .........................................................................................................5
  7.      Visitor Management .......................................................................................................5
  8.      Remote Access Level Management ................................................................................6
  9.      Third Party Interfaces ....................................................................................................6
  10.     System Administration ...................................................................................................6
  11.     Mobile Enterprise Solutions ..........................................................................................6
  12.     Badge Layout Creation and Editing ..............................................................................7
  13.     Screens/Forms Creation ................................................................................................7
  14.     Graphical Map Creation................................................................................................7
  15.     Application Programming Interfaces ............................................................................7
  16.     Data Import ....................................................................................................................7
  17.     Bi-Directional Data Exchange ......................................................................................7
  18.     API Development Toolkit ...............................................................................................8
  19.     Server Redundancy ........................................................................................................8
B.        APPLICATION DESIGN ...................................................................................................8
  1.      Single, Unified Source Code Set ....................................................................................8
  2.      Microsoft Gold Certified Partner ..................................................................................9
  3.      Microsoft Windows XP Certification .............................................................................9
  4.      Single License Key Systems ...........................................................................................9
  5.      Concurrent Licensing.....................................................................................................9
  6.      Single Sign-On Support..................................................................................................9
  7.      Unicode Support ..........................................................................................................10
  8.      Open Architecture ........................................................................................................10
     a)   Open Database Connectivity Compliance ...................................................................11
     b)   Open Application Architecture ....................................................................................11
     c)   Scalability ....................................................................................................................11
     d)   Portability.....................................................................................................................12
     e)   Network Support ..........................................................................................................12
     f)   Video Input Support .....................................................................................................12
     g)   Credential Printer Support ...........................................................................................12
  11.     32-bit Application ........................................................................................................13
  12.     Application Partitioning ..............................................................................................13
  13.     Easy to Use, Graphical User Interface ........................................................................13
  14.     Support for Microsoft Windows Installer ....................................................................13
  15.     Distributed Local Decision Making .............................................................................14
  16.     Application Installation ...............................................................................................14
  17.     System Management Console ......................................................................................14
  18.     System User Feedback Tool .........................................................................................14
  19.     Multimedia Integration ................................................................................................14
  20.        Advanced Network Architecture ..................................................................................14
  21.        Object Oriented Programming ....................................................................................15
C.           OPERATING SYSTEM ...................................................................................................15
  1.         Interface .......................................................................................................................15
  2.         Networking ...................................................................................................................15
  3.         Remote Management ....................................................................................................15
  4.         Remote Access Services (RAS) .....................................................................................15
  5.         Security ........................................................................................................................16
D.           VIRTUAL ENVIRONMENT.............................................................................................16
E.           CLIENT/SERVER RELATIONAL DATABASE MANAGEMENT SYSTEMS .......................16
  1.         Preservation of Data Integrity .....................................................................................17
     a)      Transaction Processing ................................................................................................17
     b)      Enforced Data Integrity................................................................................................17
     c)      User-Defined Data Types ............................................................................................17
     d)      Encrypted User Defined Fields ....................................................................................17
     d)      Defaults ........................................................................................................................18
     e)      Rules ............................................................................................................................18
  2.         Mature Client/Server Architecture ..............................................................................18
  3.         N-tier architecture .......................................................................................................18
  4.         Advanced Thin Client Architecture ..............................................................................19
E.           NETWORK DESIGN ......................................................................................................19
F.           GRAPHICAL USER INTERFACE ....................................................................................20
G.           MIGRATION & UPGRADES ..........................................................................................21
H.           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
   o) Remote Monitor .........................................................................................................136
   p) Video Authentication .................................................................................................137
   q) 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
  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)   Assigning Access Levels ...........................................................................................205
  h)   Temporary Access Level Assignments ......................................................................205
  i)   Bulk Assignment of Activate/Deactivate Dates to Access Levels ............................205
  j)   Associated Video .......................................................................................................206
  k)   Remote Access Level Management Reports .............................................................206
  l)   On-Line Context Sensitive Help ................................................................................206
12.    Third Party Interfaces ................................................................................................207
  a)   Overview ....................................................................................................................207
  b)   OPC Server Support ...................................................................................................207
  c)   OPC Client Support ...................................................................................................207
  d)   SNMP Support ...........................................................................................................207
  e)   IBM WebSphere Adapter ..........................................................................................208
  f)   Microsoft Queues Adapter .........................................................................................208
  g)   Fire Alarm Interface ...................................................................................................208
  h)   Intercom Interface ......................................................................................................209
  i)   Point of Sale Interface ................................................................................................210
  j)   Personal Safety System Interface...............................................................................211
  k)   Central Station Alarm Receiver Interface ..................................................................213
  l)   Smart Card Readers ...................................................................................................213
  m)    Smart Card Life Cycle Management .......................................................................214
  n)   Otis Compass Destination Entry System Elevator Interface .....................................214
  o)   Barco Integration .......................................................................................................214
  p)   Onity Integra Offline Locks Integration ....................................................................214
13.    System Administration ...............................................................................................223
  a)   System Configuration ................................................................................................223
  b)   Pre-defined Database .................................................................................................223
  c)   System Configuration Setup Wizards ........................................................................223
  i)   Multiple Language Support .......................................................................................223
  j)   Single Sign-on Support ..............................................................................................224
  k)   Password Privileges ...................................................................................................224
  g)   Strong Passwords .......................................................................................................224
  h)   System Operators .......................................................................................................224
  i)   System Permissions ...................................................................................................225
  j)   Network Account Management .................................................................................225
  k)   System Operator Activity Logging ............................................................................226
  l)   Alarm/Event Activity Logging ..................................................................................227
  m)    Encryption of PIN Codes inside the Database Server .............................................228
  n)   Access Control Reports..............................................................................................228
  o)   On-Line Documentation ............................................................................................241
  p)   Ad-hoc Database Report Generator ...........................................................................241
  q)   Custom Report Writer ................................................................................................242
  r)   System Tape Backup..................................................................................................242
  s)   Client workstations ....................................................................................................242
  t)   PIN Numbers .............................................................................................................242
  u)   List Builder ................................................................................................................243
  v)   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)   SYSTEM API Toolkit Operations .............................................................................268
    b)   Accepting Custom Incoming Alarms and Events ......................................................268
    c)   DataConduIT Devices and Sub-Devices ...................................................................269
  22.    Open Protocol Interface ............................................................................................270
  23.    Open Supervised Reader Interface ............................................................................271
         SECTION III - WORKSTATION & PERIPHERAL
         REQUIREMENTS ............................................................................... 273
A.       DATABASE SERVERS ..................................................................................................274
  1.     Servers for Windows 2008/2003 Access Control & Alarm Monitoring Systems .......274
  2.     Servers for Windows 2008/2003 PRO Access Control & Alarm Monitoring Systems275
  3.     Servers for Windows 2008/2003 Credential Management Systems ..........................276
  4.     Servers for Windows 2008/2003 Credential Management Systems ..........................277
  5.     Servers for Windows 2008/2003 Integrated Systems .................................................278
  6.     Servers for Windows 2008/2003 Integrated Systems .................................................279
B.       CLIENT WORKSTATIONS PC SPECIFICATIONS ........................................................280
  1.     Client Workstations for Windows 2008/2003 SYSTEMS ...........................................280
C.       CLIENT WORKSTATIONS TYPES ...............................................................................281
  1.     Administration............................................................................................................281
  2.     Alarm Monitoring ......................................................................................................281
  3.     Viewing ......................................................................................................................281
  4.     Editing ........................................................................................................................281
  5.     Enrollment and Badging ............................................................................................282
  6.     Printing ......................................................................................................................282
  7.     Asset Management .....................................................................................................282
  8.     Digital Video ..............................................................................................................282
  9.     Intrusion Detection ....................................................................................................282
  10.    Visitor Management ...................................................................................................283
  11.    Remote Access Level Management ............................................................................283
  12.    Integrated ...................................................................................................................283
D.       PERIPHERALS ............................................................................................................284
  1.     Video Camera ............................................................................................................284
  2.     Video Capture Board .................................................................................................285
  3.     Direct Card Printer....................................................................................................287
  4.     Signature Capture Tablet...........................................................................................289
  5.     Report Printer ............................................................................................................290
  6.     Event Printer ..............................................................................................................291
  7.     Modem........................................................................................................................292
  8.     Tape Backup System ..................................................................................................293
         SECTION IV - ACCESS CONTROL FIELD HARDWARE
         DEVICES .............................................................................................. 295
A.       OVERVIEW .................................................................................................................295
 1.      Intelligent System Controller (ISC) ...........................................................................296
 2.      Intelligent Dual Reader Controller (IDRC)...............................................................298
 2.      Input Control Module (ICM) .....................................................................................301
3.     Output Control Module (OCM) .................................................................................302
4.     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
     SYSTEM’s 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.   Access Control
            B.   Alarm Monitoring
            C.   Credential Management
            D.   Digital Video Management
            E.   Intrusion Detection Management
            F.   Asset Management
            G.   Visitor Management
            H.   Remote Access Level Management
            I.   Third Party Interfaces
            J.   System Administration
            K.   Mobile Enterprise Solutions
            L.   Badge Layout Creation
            M.   Screen/Forms Creation
            N.   Graphical Map Creation
            O.   Application Programming Interfaces
            P.   Data Import
            Q.   Bi-Directional Data Exchange
            R.   API Development Toolkit
            S.   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 individual’s 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                                                            SYSTEM ARCHITECTURE

  4. Digital Video Management
     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 object-
     oriented 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                                                             SYSTEM ARCHITECTURE

              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.
  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                                                              SYSTEM ARCHITECTURE

           a) Open Database Connectivity Compliance
               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 SYSTEM’s dedicated
               database server, meaning only the SYSTEM’s 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 cardholder’s, visitors’, and
               asset’s 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, multi-
     threading 32-bit or 64-bit operating system. The SYSTEM software shall be a true, native 32-
     bit 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 Microsoft’s 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 multi-
  tasking, 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                                                          SYSTEM ARCHITECTURE

  5. Security
     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 SYSTEM’s 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 SYSTEM’s 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 SYSTEM’s 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 SYSTEM’s 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                                                             SYSTEM ARCHITECTURE

           d) Defaults
              The SYSTEM’s 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 SYSTEM’s RDBMS shall enforce rules, which are integrity constraints that
              go beyond those implied by a field’s 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 SYSTEM’s 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                                                            SYSTEM ARCHITECTURE

             8. NFS Networks

             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 CUSTOMER’s 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 SYSTEM’s 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
          • Last Name                                          • Home Phone
          • Middle Initial                                     • Birth Date
          • Social Security Number                             • Title
          • Badge Type                                         • Cardholder Number
          • Department                                         • Office Phone
      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 user-
      definable 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                                                    FUNCTIONAL REQUIREMENTS

      Access Control
      a) Time Zones
      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 decision-
      making.

      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 reader’s 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 pre-
      defined time of day based on that card reader’s 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 cardholder’s 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 cardholder’s
      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 SYSTEM’s 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                                      •     Device Groups
             •   Access Levels                                      •     Digital Video Archive
                                                                          Server
             •   Actions
                                                            •   Fire Panels
             •   Action Groups
                                                            •   Guard Tours
             •   Alarm Inputs
                                                            •   Global I/O Function Lists
             •   Alarm Mask Groups
                                                            •   Global I/O Links
             •   Alarm Outputs
                                                            •   Holidays
             •   Alarms
                                                            •   Intercom Panels
             •   Areas
                                                            •   Intercom Stations
             •   Badge Types
                                                            •   Intrusion Detection Panels
             •   Card Formats
                                                            •   ISCs
             •   Cardholders

                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                   Functional Specifications Version 6.3 Series                     Page 29
SECTION II                                                      FUNCTIONAL REQUIREMENTS

      •    Maps                                             •   Card Readers
      •    Monitor Zones                                    •   Central Station Receivers
      •    Personal Safety Panels                           •   System Operators
      •    Precision Access Groups                          •   Time Zones
      •    Receiver Accounts                                •   Visitors
      •    Tour Groups                                      •   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 ISC’s
      configuration, either a full download of all cardholders or a selective download of
      specified access level shall occur.

      Dial–up 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                                                     FUNCTIONAL REQUIREMENTS

                 2.   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.
                 3.   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.
                 4.   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.
      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                                                    FUNCTIONAL REQUIREMENTS

             1) Global Hard Anti-passback
             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 area’s
             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 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 area’s 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 Anti-
             passback:
                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 anti-
                   passback 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 anti-
                   passback 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                                                    FUNCTIONAL REQUIREMENTS

             5) Designated One-Person Control
             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                                                     FUNCTIONAL REQUIREMENTS

              7) Alarm Monitoring
              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 list’s 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                                                      FUNCTIONAL REQUIREMENTS

                     INPUT EVENTS                  POSSIBLE STATES
                     Cabinet Tamper, Power         Not Configured, Secure, Fault, Alarm
                     Failure

   2) For Card Reader Events:

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

   3) For Input Control Module Events:

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

   4) For Host Computer Events:

                     INPUT EVENTS                  POSSIBLE STATES
                     Communication Status          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 SYSTEM’s 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                                                       FUNCTIONAL REQUIREMENTS

      An access level shall be set as:

                  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
              cardholder’s 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 cardholder’s 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 badge’s
      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 reader’s
      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 reader’s door to be held open for an extended period of time beyond the pre-
      determined 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.   Activating/Deactivating Outputs
                2.   Masking/Unmasking Inputs
                3.   Changing Reader Modes
                4.   Executing Function Lists
                5.   Opening/Closing Areas
                6.   Sending Email
                7.   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.   Checkpoint Reached on Time
                2.   Checkpoint Reached Early
                3.   Checkpoint Overdue
                4.   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                                                    FUNCTIONAL REQUIREMENTS

             4) Guards
             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.   Checkpoint Sequence Number
                2.   Checkpoint Name
                3.   Checkpoint Status
                4.   Checkpoint Min Time
                5.   Checkpoint Max Time
                6.   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.    Checkpoint Not Reached
                 2.    Checkpoint Reached On Time
                 3.    Checkpoint Reached Early
                 4.    Checkpoint Overdue
                 5.    Checkpoint Reached Late
                 6.    Checkpoint Out of Sequence
                 7.    Checkpoint Missed
                 8.    Guard Tour Initiated
                 9.    Guard Tour Completed
                 10.   Guard Tour Completed With Errors
                 11.   Guard Tour Cancelled
                 12.   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 cardholder’s 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                                                       FUNCTIONAL REQUIREMENTS

           bb) Alarm/Event Logging
      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.    Action Group
                  2.    Event Archiving/Purging
                  3.    Arm/Disarm Area
                  4.    Start of Guard Tour
                  5.    Execution of DataExchange Scripts
                  6.    Activate, Deactivate, Pulse Device Output
                  7.    Activate, Deactivate, Pulse Device Output Group
                  8.    Global Anti-Passback Reset
                  9.    Download Firmware to ISCs
                  10.   Download Firmware to Lenel Network Video Recorders
                  11.   Download Firmware to IP Cameras
                  12.   Download Database to ISCs
                  13.   Execute Function List
                  14.   Mask/Unmask Inputs
                  15.   Mask/Unmask Input Groups
                  16.   Mask/Unmask Alarm Mask Group


                        LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                    Functional Specifications Version 6.3 Series                    Page 52
SECTION II                                                       FUNCTIONAL REQUIREMENTS

                17.   Mask/Unmask Door Forced Opens
                18.   Mask/Unmask Door Forced Opens for Reader Group
                19.   Mask/Unmask Door Held Opens
                20.   Mask/Unmask Door Held Opens for Reader Group
                21.   Open Door
                22.   Open Door Group
                23.   Change Reader Mode
                24.   Automatic Reports
                25.   Reset Use Limit
                26.   Move Bulk Badges From Area
                27.   Deactivate Badges
                28.   Logout Visitors
                29.   Schedule PTZ preset
             The Scheduling Utility shall provide a flexible scheduling mechanism to satisfy a
             wide range of scheduling needs, such as:

                1.    Every day, on the hour
                2.    Every Monday at 8:00 am
                3.    The first Sunday of every month
                4.    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.    Daily: Every n day(s).
                2.    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.
                3.    Monthly: This shall provide two options:

                      LENEL - A UTC FIRE & SECURITY COMPANY
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.   Once, at a given time.
                2.   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.   Start date (defaults to current date).
                2.   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.   Next Start Date/Time
                2.   Last Start Date/Time
                3.   Last End Date/Time
                4.   Last Run Duration (calculated from start and end times).
                5.   Last Run Status (e.g. Successful, Error)
                6.   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                                                      FUNCTIONAL REQUIREMENTS

      dd)     Multiple Card Formats
      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.   Unknown PIN entry at a card reader configured as ‘PIN or Card’ mode

              2.   Invalid cipher entry at a card reader in Cipher Mode

              3.   Invalid PIN entered for a given card at a card reader configured as
                   ‘Card and PIN’ mode

              4.   Non-matching biometric presented for a given card at a card reader in
                   biometric verify mode.

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

              1.   10 minutes pass without any of the above denial types

              2.   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 reader’s 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                                    •   Execute function
                                                                             lists
                     •   Open doors
                                                                         •   Paging
                     •   Relay and reader
                         outputs                                         •   E-mail
                     •   Set panel clock                                 •   Panel dialup
                     •   Mask alarms and                                 •   Standalone test
                         inputs                                              mode
                     •   Unmask alarms                                   •   Download
                         and inputs                                          firmware
                     •   Mask alarm mask                                 •   Arm areas
                         groups
                                                                         •   Disarm areas
                     •   Unmask alarm
                                                                         •   Silence area
                         mask groups
                                                                             alarms



                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                  Functional Specifications Version 6.3 Series                   Page 57
SECTION II                                                     FUNCTIONAL REQUIREMENTS

      kk) Alarm/Event Routing
      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 Operator’s
      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                                                      FUNCTIONAL REQUIREMENTS

           pp) Alarm-Event Mappings
      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 ISC’s 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 reader’s 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 reader’s auxiliary inputs. As an example, “aux input 1”at 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 reader’s 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 reader’s 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 reader’s 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 ISC’s 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

      •       When disarmed, an audible chime when programmed point in the group change
      state




                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                 Functional Specifications Version 6.3 Series                Page 67
SECTION II                                                    FUNCTIONAL REQUIREMENTS

  2. Alarm Monitoring
      a) Alarms Monitored
      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 right-
      mouse 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 Administrator’s 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                                                      FUNCTIONAL REQUIREMENTS

              (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
              (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 alarm’s 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 alarm’s
      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 cardholder’s 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 cardholder’s 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 that’s 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                                                     FUNCTIONAL REQUIREMENTS

      n) Real-Time, Live Video User Verification
      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 cardholder’s 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                                   11. Intrusion Area
             2. Time/Date                                           12. Text
             3. Panel                                               13. Line Number
             4. Panel Time                                          14. Intercom Station Called
             5. Device                                              15. Account Group
             6. Input/Output                                        16. Transmitter
             7. Cardholder                                          17. Transmitter Input
             8. Badge Type                                          18. Asset Scan ID
             9. Priority                                            19. Asset Name
             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


                    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 real-
      time 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.
               3. Upon alarm acknowledgment or clearing the alarm:
                  •   Shall allow the camera, monitor, and VCR to be set back to reset positions
                      or normal operation automatically.
      The CCTV system requires either a serial RS-232 or a parallel port interface to a micro-
      processor 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)                           •   Macintosh PICT (.pct)
           •   AutoCAD DXF (.dxf)                               •   MacPaint (.mac)
           •   CALS Raster (.cal)                               •   Microsoft Paint (.msp)
           •   Encapsulated Post Script                         •   Port Net Graphics (.png)
               (.eps)
                                                                •   Sun Raster (.ras)
           •   GEM/Ventura (.img)                               •   Targa (.tga)
           •   IBM IOCA (.ica)
                                                                •   TIFF (.tif)
           •   JPEG (.jpg)                                      •   Windows Metafile (.wmf,
           •   JIFF (.jif)                                          .emf)
           •   Kodak Photo-CD (.pcd)                            •   Windows Bitmap (.bmp, .dib)
           •   Kodak Flashpix (.fpx)                            •   WordPerf Raster (.wpg)
           •   LEAD (.cmp)                                      •   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.

             2.   Offline Counter - a counter of the number of offline devices in the
                  Monitoring Zone.


                     LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                  Functional Specifications Version 6.3 Series                     Page 82
SECTION II                                                      FUNCTIONAL REQUIREMENTS

             3.   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.   Device Name

             2.   ISC/ICM/OCM Name

             3.   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.   Include All Devices

             2.   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
      cardholder’s 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 Operator’s 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                                                    FUNCTIONAL REQUIREMENTS

      ll) Hardware Update Timer
      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                                                     FUNCTIONAL REQUIREMENTS

  3. Personnel Management and Enrollment
  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 cardholder’s 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 cardholder’s 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 cardholder’s 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 badge’s 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 de-
      activated.

      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
      cardholder’s 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 cardholder’s 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 cardholder’s 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                                                     FUNCTIONAL REQUIREMENTS

           i) Mobile Badging Operations
      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" high-
              coercivity 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 HSPD-
             12.

             Support shall be provided for reading the 200 bit BCD FASC-N output of FASC-
             N 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 FASC-
             N 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 FIPS-
             201. The SYSTEM shall allow for the verification of the cardholder’s 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                                                     FUNCTIONAL REQUIREMENTS

  4. Enrollment & Credential Creation
           a) Enrollment
      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 cardholder’s 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 subject’s 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 on-
      line.

      The System Operators shall have the ability to freeze and unfreeze the cardholder’s 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 cardholder’s 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 on-
      line.

      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
      cardholder’s image at the time of enrollment. The SYSTEM must support the following
      image formats:

           •   Bitmaps (.bmp, .dib)                       •   Macintosh PICT (.pct)
           •   JPEG (.jpg)                                •   Portable Network Graphics (.png)
           •   JIFF (.jif)                                •   TIFF (.tif)
           •   Zsoft PCX/DCX (.pcx, .dcx)                 •   Windows Metafile (.wmf, .emf)
           •   Adobe Photoshop (.psd)                     •   Targa (.tga)
           •   CALS Raster (.cal)                         •   Kodak Photo CD (.pcd)
           •   GEM/Ventura IMG (.img)                     •   Kodak Flashpix (.fpx)
           •   IBM IOCA (.ica)                            •   Encapsulated Post Script
                                                              (.eps)
           •   WordPerfect Raster (.wpg)


      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 on-
      line.

      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 Driver’s 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 V-
      Station 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 cardholder’s
      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 Windows-
              compatible 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.
                2.   Revoke Certificates.
                3.   Renew Certificates.
                4.   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.
           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 Windows-
                compatible 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 Operator’s

                     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
      cardholder’s 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
      cardholder’s 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 cardholder’s 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 Dennison’s 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
      cardholder’s 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 driver’s 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 II-
      capable 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 photo’s
      image.




                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                  Functional Specifications Version 6.3 Series                 Page 112
SECTION II                                                       FUNCTIONAL REQUIREMENTS

           p) Bar-code Support
      The SYSTEM shall support the following bar codes:

           •   Code 3 of 9 (3:1)                                 •   PostNet (Zip +4 Postal)
           •   Code 93                                           •   Code 3 of 9 (2:1)
           •   UPCA                                              •   Interleaved 2 of 5 (2:1)
           •   EAN 13                                            •   PDF-417 (2D)
           •   EAN 8                                             •   Code 128 Auto
           •   Code 128 A                                        •   UCC-128
           •   Code 128 B                                        •   MSI Plessey
           •   Code 128 C                                        •   Extended Code 3 of 9
           •   Codabar                                           •   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                                                     FUNCTIONAL REQUIREMENTS

           o Agency Card Serial Number

           o Issuer Identification



           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 Manufacturer’s
      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 Manufacturer’s 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
      Operator’s 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
              customer’s 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 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 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 pre-
             defined 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                                                    FUNCTIONAL REQUIREMENTS

                     4) Audio Support
             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 camera’s 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
             camera’s 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 SYSTEM’s 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                                                     FUNCTIONAL REQUIREMENTS

           k) 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 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
                 SYSTEM’s 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 Operator’s 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                                                    FUNCTIONAL REQUIREMENTS

                       a. 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.

                       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 source’s 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                            7. Focus Near

                2. Pan Right                           8. Focus Far

                3. Tilt Up                             9. Iris Open

                4. Tilt Down                           10. Iris Close

                5. Zoom In                             11. Go to Preset

                6. Zoom Out                            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 Operator’s 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                                                    FUNCTIONAL REQUIREMENTS

                     18) Presets on Alarm
             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 pre-
      recorded video. The automated motion video search shall analyze frames in a pre-
      configured 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                                                      FUNCTIONAL REQUIREMENTS

           o) Remote Monitor
      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 RM’s 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 RMC’s 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 Operator’s 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 customer’s 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 pre-
              defined 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                                                      FUNCTIONAL REQUIREMENTS

                     4) Individual LDVR Output Setup
              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 browser-
      based 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 Operator’s 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                                                    FUNCTIONAL REQUIREMENTS

                    1) Real Time Monitoring
             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                                                    FUNCTIONAL REQUIREMENTS

                       f. 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.

                    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                                             3. Tilt Up

                2. Pan Right                                            4. Tilt Down

                   LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                 Functional Specifications Version 6.3 Series                  Page 150
SECTION II                                                      FUNCTIONAL REQUIREMENTS

                5. Zoom In                                               9. Iris Open

                6. Zoom Out                                              10. Iris Close

                7. Focus Near                                            11. Go to Preset

                8. Focus Far                                             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                                                     FUNCTIONAL REQUIREMENTS

                    8) 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. 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                                                     FUNCTIONAL REQUIREMENTS

           n) Intelligent Motion Video Searching
      The DVMS shall support advanced automated motion video searching against pre-
      recorded 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 camera’s 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                                                      FUNCTIONAL REQUIREMENTS

  7. Intelligent Video
           a) Overview
      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.   Smart VMD
                                 b.   Invalid Camera
                                 c.   Object Left Behind
                                 d.   Object Removed
                                 e.   Object Detection
                                 f.   Congestion
                                 g.   Directional Motion
                                 h.   Object Crosses a Region
                                 i.   Object Stops
                                 j.   Object Starts to Move
                                 k.   Object Moves too Fast
                                 l.   Object Lurking
                                 m.   Loitering
                                 n.   Facial Detection
                                 o.   People Counting

           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
SECTION II                                                    FUNCTIONAL REQUIREMENTS

                    4) Object Removed
             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                                                      FUNCTIONAL REQUIREMENTS

                      12) Object Lurking
              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                                                     FUNCTIONAL REQUIREMENTS

           k) On-line Context Sensitive Help
     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                                                       FUNCTIONAL REQUIREMENTS


  8. Intelligent Video Solutions
           a) Overview
      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 camera’s 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.    Bosch D9412

                    2.    Bosch D7412

                    3.    Bosch D9412G

                    4.    Bosch D7412G

                    5.    Bosch D9412GV2

                    6.    Bosch D7412GV2

                    7.    Detection Systems DS7400Xi

                    8.    Detection Systems DS7400Xi Version 4+

                    9.    Honeywell Galaxy 8

                    10.   Honeywell Galaxy 18

                    11.   Honeywell Galaxy 60

                    12.   Honeywell Galaxy 128

                    13.   Honeywell Galaxy 500

                    14.   Honeywell Galaxy 504

                    15.   Honeywell Galaxy 512

                    16.   Guardall xL

                    17.   Guardall PX

                    18.   Guardall QX

                    19.   Guardall RX

             The intrusion detection panel’s 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.    D9412 shall support 246 zones

                           2.    D7412 shall support 75 zones

                           3.    7400Xi shall support 128 zones

                           4.    7400Xi 4+ shall support 248 zones

                           5.    Honeywell Galaxy 8 shall support 8 zones

                           6.    Honeywell Galaxy 18 shall support 18 zones

                           7.    Honeywell Galaxy 60 shall support 60 zones

                           8.    Honeywell Galaxy 128 shall support 128 zones

                           9.    Honeywell Galaxy 500 shall support 500 zones

                           10.   Honeywell Galaxy 504 shall support 504 zones

                           11.   Honeywell Galaxy 512 shall support 512 zones

                           12.   Guardall xL shall support up to 256 zones, depending
                                 on model

                           13.   Guardall PX shall support up to512 zones, depending
                                 on model

                           14.   Guardall QX shall support up to 32 zones, depending
                                 on model

                           15.   Guardall RX shall support up to 32 zones, depending on
                                 model


                   LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                 Functional Specifications Version 6.3 Series                Page 164
SECTION II                                                     FUNCTIONAL REQUIREMENTS

                     3) Intrusion Detection Areas
              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.   Firmware Version                                 6.    Valid Local Access (R)

             2.   Online status                                    7.    RF Receiver Trouble (R)

             3.   Internal Event Log                               8.    Failed to Call RAM (R)
                  Threshold Reached (R)
                                                                   9.    User Code Tamper (R)
             4.   Internal Event Log
                  Wrapped (R)                                      10.   SDI Device is Failed (R)

             5.   Point Bus Failed since it                        11.   Receiver Communications
                  Last Reported (R)                                      Has Failed (R)

                     LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                  Functional Specifications Version 6.3 Series                   Page 166
SECTION II                                                          FUNCTIONAL REQUIREMENTS

                12.   AC Failure (R, DS)                      18.   Report Failure (DS)

     13.    Battery is Missing (R)                            19.   Control Fault (DS)

     14.    Battery is Low (R, DS)                            20.   MPX Bus Fault (DS)

     15.    Parameter Checksum Failed (R)                     21.   Radio RX Fault (DS)

      16.   Phone Line Failed (R)                             22.   AUX Power Fault (DS)

      17.   Extra RF point (R)                                23.   Option Fault (DS)




                         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.    Bypassed/Unbypassed                      12.   Day Monitor Alarm (DS)

             2.    Forced/Not Forced (R,                    13.   Output Latched (DS)
                   DS)
                                                            14.   Short Circuit Fault (G)
             3.    Normal, Shorted, Open,
                   Missing (Not Responding),                15.   Open Circuit Fault (G)
                   Not Defined (Not
                   Programmed)                              16.   Low Resistance (G)

             4.    Unacknowledged/Ackno                     17.   High Resistance (G)
                   wledged (R)                              18.   RF Lid Tamper – only RF zones
             5.    Explicit Trouble (DS)                          (G)

             6.    Tamper (DS)                              19.   RF Supervision Fail – only RF
                                                                  zones (G)
             7.    Low Battery [Radio
                   Zone] (DS)                               20.   RF Low Battery – only RF zones
                                                                  (G)
             8.    No Signal Strength
                   [Radio Zone] (DS)                        21.   RF Zone Fob Deleted – only RF
                                                                  zones (G)
             9.    Alarm (unrestored) (DS,
                   G)                                       22.   If the zone is RF or normal (G)

             10.   Trouble (unrestored) (DS)                23.   Suspended (G)

             11.   Untested (DS)
             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.    Disarmed                                          5.   Master Armed (R)

             2.    Not In Use (R, DS)                                6.   Perimeter Instant Armed (R)

             3.    Entire Partition Armed (DS,                       7.   Perimeter Delay (R)
                   G)
                                                                     8.   Area Entry Delay (R)
             4.    Perimeter Armed (DS)
                                                                     9.   Perimeter Entry Delay (R)


                      LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                   Functional Specifications Version 6.3 Series                     Page 168
SECTION II                                                       FUNCTIONAL REQUIREMENTS

             10.   Area Exit Delay (R)                               14.   Suspend (G)

             11.   Perimeter Exit Delay (R)                          15.   Partial Arm (G)

             12.   Master Armed Instant (R)

             13.   Setting (G)

             Additional Area Status:

                      1.   Not Ready To Arm (R)

                      2.   Area Points Bypassed (R)

                      3.   Area Forced Points (R)

                      4.   Alarm Status (R)

                      5.   System (G)

                      6.   PA Alarm (G)

                      7.   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)
                      2.   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)

                      LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                    Functional Specifications Version 6.3 Series                     Page 169
SECTION II                                           FUNCTIONAL REQUIREMENTS

                • Held Open/Not Held Open (R)




             LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®        Functional Specifications Version 6.3 Series         Page 170
SECTION II                                                      FUNCTIONAL REQUIREMENTS

           d) Command and Control Functionality
                     1) Intrusion Panel Commands
              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                                                       FUNCTIONAL REQUIREMENTS

                    4) Onboard Relay Commands
             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                                                     FUNCTIONAL REQUIREMENTS

           e) System Events
      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                                       •     User Code Change
              •   Burglary Alarm                                   •     Time Change
              •   Keypad Fire                                      •     Date Change
              •   Keypad Emergency                                 •     Access Code Used
              •   Keypad Panic                                     •     Auto Arming Time
                                                                         Change
              •   Open
                                                                   •     Remote Programming
              •   Close
                                                                         Access
              •   Bypass (24Hr, Fire,
                                                                   •     Local Programming
                  Supervisory)
                                                                         Access
              •   Bypass (forced or when
                                                                   •     Fire Trouble (Fire or
                  closed)
                                                                         Supervisory Zone)
              •   Unbypass (24Hr, Fire,
                                                                   •     Supervisory
                  Supervisory)
                                                                   •     Temporary Code
              •   Trouble (Zone)
                                                                         Expiration Date Change
              •   Restoral (Zone)
              •   Trouble (System)
              •   Restoral (System)




                     LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                  Functional Specifications Version 6.3 Series                    Page 173
SECTION II                                                      FUNCTIONAL REQUIREMENTS

                    2) Bosch 7412/9412 Events
             •   Access Granted                                     •     Fire Walk Start
             •   Duress                                             •     Fire Walk End
             •   User Alarm                                         •     Walk Test Start
             •   Bypass Point                                       •     Walk Test End
             •   Forced Point                                       •     Fail Open
             •   Fire Alarm                                         •     Fail Close
             •   Fire Trouble                                       •     Area Watch
             •   Fire Missing                                       •     Walk Test Point
             •   Fire Restoral from Alarm                           •     Extend Close Time
             •   Fire Restoral from                                 •     Non-Fire Cancel
                 Trouble
                                                                    •     Opening
             •   Alarm
                                                                    •     Forced Close
             •   Trouble
                                                                    •     Closing
             •   Restoral from Trouble
                                                                    •     Test Report
             •   Missing Alarms
                                                                    •     Log Threshold
             •   Missing Troubles
                                                                    •     Log Overflow
             •   Point Opening
                                                                    •     Parameter Change
             •   Point Closing
                                                                    •     User Code Tamper
             •   Extra Point
                                                                    •     User Code Change
             •   Point Bus Fail
                                                                    •     Sked Execute
             •   All Points Tested
                                                                    •     Sked Change
             •   Restoral from Alarm
                                                                    •     Date Change
             •   Fire Cancel
                                                                    •     Time Change
             •   User Code Added
                                                                    •     User Level Set
             •   Service Start
                                                                    •     Valid Access
             •   Sensor Reset
                                                                    •     Invalid Access
             •   Relay Set
                                                                    •     Valid Remote
             •   Relay Reset
                                                                    •     Invalid Remote
             •   Force Arm
                                                                    •     Comm Fail
             •   Create Status Report

                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                   Functional Specifications Version 6.3 Series                     Page 174
SECTION II                                                      FUNCTIONAL REQUIREMENTS

             •   Comm Restoral                                      •     RF Tamper Alarm
             •   Phone Fail                                         •     RF Tamper Trouble
             •   Phone Restoral                                     •     Equipment Restoral
             •   SDI Device Fail                                    •     Assign Card
             •   SDI Device Restoral                                •     Delete Card
             •   AC Fail                                            •     Cycle Door
             •   AC Restoral                                        •     Door Unlocked
             •   Battery Missing                                    •     Door Secured
             •   Battery Low                                        •     No Entry (Access
                                                                          Denied)
             •   Battery Restoral
                                                                    •     Door Left Open
             •   Watch Dog Reset
                                                                    •     Door Request
             •   Supervision (non-fire)
                                                                    •     Network Fail
             •   Remote Reset
                                                                    •     Network Restore
             •   Checksum Fail
                                                                    •     Network Condition
             •   Memory Fail
                                                                    •     Equipment Fail
             •   Re-Boot
                                                                    •     Fire Supervision Restored
             •   Parameter Checksum Fail
                                                                    •     Fire Supervision
             •   Force Perimeter Instant
                                                                    •     Fire Supervision Trouble
             •   Force Perimeter Delay
                                                                    •     Fire Supervision Trouble
             •   Perimeter Instant
                                                                          Restore
             •   Perimeter Delay
                                                                    •     Extra Account
             •   Delete User
                                                                    •     Low Signal Strength
             •   Point Bus Restore
                                                                    •     RF Receiver Tamper
             •   RF Battery Low
                                                                    •     RF Receiver Restore
             •   RF Battery Restore                                       from Tamper
             •   RF Tamper Restore                                  •     RF Interference Restoral
             •   RF Receiver Trouble                                •     Sensor Trouble
             •   RF Extra Point                                     •     Sensor Trouble Restore
             •   RF Receiver Restore                                •     Door Locked
                 From Trouble
                                                                    •     Missing Fire Supervision
             •   RF Interference

                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                   Functional Specifications Version 6.3 Series                      Page 175
SECTION II                                                    FUNCTIONAL REQUIREMENTS

             •   Missing Supervision                              •     Low Temperature Restore
                 (non-fire)
                                                                  •     Unverified Event
             •   Fail to Execute
                                                                  •     Abort
             •   Analog Service
                                                                  •     Service Request
             •   Analog Restore
                                                                  •     Output State
             •   Test Failed
                                                                  •     Output State Restore
             •   External Device
                                                                  •     Bypass Restore
             •   Custom Function
                                                                  •     Alarm Silenced
                 Executed
                                                                  •     Alarm Panel Substitution
             •   Low Temperature




                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                 Functional Specifications Version 6.3 Series                      Page 176
SECTION II                                                  FUNCTIONAL REQUIREMENTS

             f) Bosch 7412/9412 Events
                   •     Communications                                   Ended
                         Lost
                                                                      •   Log Threshold
                   •     Communications                               •   Manual Test
                         Restored
                                                                      •   Parameter
                   •     Access                                           Checksum
                         Granted                                          Fail
                   •     Access Denied                                •   Phone Line
                   •     Holdup Alarm                                     Restore
                   •     Holdup                                       •   Phone Line
                         Bypass                                           Trouble
                   •     Holdup                                       •   Power Up
                         Restore
                                                                      •   Printer Online
                   •     Holdup                                       •   Remote
                         Trouble                                          Program
                   •     Holdup                                           Begin
                         Trouble                                      •   Remote
                         Restore                                          Program
                   •     Holdup                                           Denied
                         Unbypass
                                                                      •   Remote Program
                   •     AC Restore                                       Success
                   •     Access                                       •   Schedule
                         Lockout                                          Executed
                   •     Access                                       •   System Power
                         Trouble                                          Restore
                   •     Automatic                                    •   System
                         Test                                             Battery
                                                                          Trouble
                   •     Communications
                         Fail                                         •   Test End
                   •     Communicatio                                 •   Test Report
                         ns Restore
                                                                      •   Test Start
                   •     Disarm From                                  •   Time Changed
                         Alarm
                                                                      •   Transmitter
                   •     Local Program                                    Battery
                   •     Local                                            Restore
                         Programming

               LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®               Functional Specifications Version 6.3 Series             Page 177
SECTION II                                              FUNCTIONAL REQUIREMENTS

               •     Transmitter                                  •   Panic Restore
                     Battery
                                                                  •   Panic Trouble
                     Trouble
                                                                  •   Panic Trouble
               •     User Code
                                                                      Restore
                     Tamper
                                                                  •   Panic
               •     Fire Alarm
                                                                      Unbypass
               •     Fire Bypass
                                                                  •   RF
               •     Fire Restore                                     Interference
               •     Fire Test                                    •   RF
                                                                      Interference
               •     Fire Trouble
                                                                      Restore
               •     Fire Trouble
                                                                  •   Tamper Alarm
                     Restore
                                                                  •   Tamper
               •     Fire Unbypass
                                                                      Bypass
               •     Door Forced
                                                                  •   Tamper
               •     Door Forced                                      Restore
                     Trouble
                                                                  •   Tamper
               •     Emergency                                        Unbypass
                     Alarm
                                                                  •   Untyped Zone
               •     Emergency                                        Trouble
                     Bypass
                                                                  •   Burglary
               •     Emergency                                        Alarm
                     Restore
                                                                  •   Burglary
               •     Emergency                                        Bypass
                     Trouble
                                                                  •   Burglary
               •     Emergency                                        Cancel
                     Trouble
                                                                  •   Burglary
                     Restore
                                                                      Restore
               •     Emergency
                                                                  •   Burglary Test
                     Unbypass
                                                                  •   Burglary
               •     Expansion
                                                                      Trouble
                     Restore
                                                                  •   Burglary
               •     Expansion
                                                                      Trouble
                     Trouble
                                                                      Restore
               •     Panic Alarm
                                                                  •   Burglary
               •     Panic Bypass                                     Unbypass


             LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®           Functional Specifications Version 6.3 Series             Page 178
SECTION II                                              FUNCTIONAL REQUIREMENTS

               •     Burglary                                         Bypass
                     Verified
                                                                  •   Medical
               •     Freeze Alarm                                     Restore
               •     Freeze Bypass                                •   Medical
                                                                      Trouble
               •     Freeze
                     Restoral                                     •   Medical
                                                                      Trouble
               •     Freeze                                           Restore
                     Trouble
                                                                  •   Medical
               •     Freeze                                           Unbypass
                     Trouble
                     Restore                                      •   Sprinkler
                                                                      Bypass
               •     Freeze
                     Unbypass                                     •   Sprinkler
                                                                      Restore
               •     Heat Alarm
                                                                  •   Sprinkler
               •     Heat Bypass                                      Trouble
               •     Heat Restore                                 •   Sprinkler
               •     Heat Trouble                                     Trouble
                                                                      Restore
               •     Heat Trouble
                     Restore                                      •   Sprinkler
                                                                      Unbypass
               •     Heat
                     Unbypass                                     •   Sprinkler
                                                                      Alarm
               •     Gas Alarm
                                                                  •   Water Alarm
               •     Gas Bypass
                                                                  •   Water Bypass
               •     Gas Restore
                                                                  •   Water Restore
               •     Gas Test
                                                                  •   Water Trouble
               •     Gas Trouble
                                                                  •   Water Trouble
               •     Gas Trouble
                                                                      Restore
                     Restore
                                                                  •   Water
               •     Gas Unbypass
                                                                      Unbypass
               •     Relay Close
                                                                  •   Automatic
               •     Relay Open                                       Closing
               •     Medical                                      •   Automatic
                     Alarm                                            Opening
               •     Medical                                      •   Close Area

             LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®           Functional Specifications Version 6.3 Series            Page 179
SECTION II                                              FUNCTIONAL REQUIREMENTS

               •     Closing                                      •   Late To Open
                     Extend
                                                                  •   Open Area
               •     Closing
                                                                  •   Opening
                     Report
                                                                      Report
               •     Early Open
                                                                  •   Recent
               •     Fail To Close                                    Closing
               •     Late Close




             LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®           Functional Specifications Version 6.3 Series            Page 180
SECTION II                                                     FUNCTIONAL REQUIREMENTS

           g) Status Requirements
      The following list of status reporting shall be included for SYSTEM integration, specific
      to each panel:

              Detection Systems DS7400Xi status:

              •   Firmware Revision                                •     Burglar zone alarm
                  listing.
                                                                   •     Supervisory
              •   Panel Time
                                                                   •     Fire Trouble
              •   Status of all incoming
                                                                   •     Fire zone trouble
                  events generated at the
                  panel.                                           •     Burglar zone trouble
              •   Alarm output state                               •     Open
              •   Programmable output                              •     Close
                  state
                                                                   •     Forced bypass
              •   Octal relay module state
                                                                   •     Bypass
                  for all relays
                                                                   •     Zone restoral
              •   Arming state for all areas
                                                                   •     Zone trouble restore
              •   Fire alarm
              •   Keypad fire, emergency,
                  medical


              The following status shall be retrieved for each zone:

              •   Zone active                                      •     Zone not programmed
              •   Zone short                                       •     Zone bypassed
              •   Zone open                                        •     Zone force bypassed
              •   Zone in explicit trouble                         •     Zone in alarm
              •   Zone tamper                                      •     Zone in trouble
              •   Zone not responding                              •     Zone untested
              •   Zone low battery                                 •     Zone day monitor alarm
              •   Zone no signal strength                          •     Zone output latched




                     LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                  Functional Specifications Version 6.3 Series                       Page 181
SECTION II                                                      FUNCTIONAL REQUIREMENTS

             Bosch 7412/9412 status:
             1. Point Status                                        •     Firmware Revision
             •    Unacknowledged Alarm                              •     Point Condition
                  Point Status
                                                                    •     On Board Relay Status
             •    Off Board Relay Status
                                                                    •     User Induced Area Status
             •    Unacknowledged                                          Transitions
                  Supervised Point Status
                                                                    •     Alarm Status for Areas
             •    Forced Point Status
                                                                    •     Area Points Not Ready to
             •    Unacknowledged Trouble                                  Arm
                  Point Status
                                                                    •     Area Points Bypassed
             •    Bypassed Points
                                                                    •     Area Points Forced
             •    Panel Status
                                                                    •     Get Panel Time
             •    Area Status
             •    Door Status
             •    Point Text


             1)       Galaxy status:

             •    Panel Status:                                           •   RF Supervision Fail
                                                                              (only applicable to RF
                  •   Online/offline status
                                                                              zones)
                      of the controller
                                                                          •   RF Low Battery (only
                  •   Firmware revision of
                                                                              applicable to RF zones)
                      the controller
                                                                          •   RF Zone Fob Deleted
             •    Zone Status:
                                                                              (only applicable to RF
                  •   Whether the zone is                                     zones)
                      normal or RF
                                                                          •   Bypassed
                  •   Open
                                                                          •   Alarm (unrestored)
                  •   Short Circuit Fault
                                                                          •   Suspended
                  •   Open Circuit Fault
                                                                    •     Relay Status:
                  •   Low Resistance
                                                                          •   Inactive
                  •   High Resistance
                                                                          •   Active
                  •   RF Lid Tamper (only
                                                                          •   Pulse
                      applicable to RF zones)
                                                                          •   Forced

                      LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                   Functional Specifications Version 6.3 Series                     Page 182
SECTION II                                                     FUNCTIONAL REQUIREMENTS

             •   Area Status:                                            •   Partial Arm
                 •   Disarmed                                            •   System
                 •   Setting                                             •   PA Alarm
                 •   Suspend                                             •   Tamper Alarm
                 •   Entire Partition
                     Armed




                     LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                  Functional Specifications Version 6.3 Series                     Page 183
SECTION II                                                     FUNCTIONAL REQUIREMENTS

  9. Asset Management
           a) Overview
      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 manufacturer’s 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 CUSTOMER’s 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 cardholder’s 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 visitor’s 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 pre-
      defined 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 asset’s 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 asset’s 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                                                     FUNCTIONAL REQUIREMENTS

                     5) Assigned Assets by Scan ID
              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                                                     FUNCTIONAL REQUIREMENTS

   10. Visitor Management
      a) Overview
      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 Driver’s 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 subject’s 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 visitor’s 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 cardholder’s 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                                                        FUNCTIONAL REQUIREMENTS

      j) Image Import
      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)                              •   Macintosh PICT (.pct)
           •   JPEG (.jpg)                                       •   Portable Network Graphic
                                                                     (.png)
           •   JIFF (.jif)
                                                                 •   TIFF (.tif)
           •   Zsoft PCX/DCX (.pcx, .dcx)
                                                                 •   Windows Metafile (.wmf,
           •   Adobe Photoshop (.psd)
                                                                     .emf)
           •   CALS Raster (.cal)
                                                                 •   Targa (.tga)
           •   GEM/Ventura IMG (.img)
                                                                 •   Kodak Photo CD (.pcd)
           •   IBM IOCA (.ica)
                                                                 •   Kodak Flashpix (.fpx)
           •   WordPerfect Raster (.wpg)
                                                            • 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
      cardholder’s 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 visitor’s 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.   All visits currently in progress (signed-in)

             2.   Visitors due in during the next user defined minutes

             3.   Visitors whose visit should have started, but who have not checked in

             4.   Visits due to expire in the next user defined minutes

             5.   Overstayed visits

             6.   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                                                     FUNCTIONAL REQUIREMENTS

           v) Visitor Tracing
      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 cardholder’s 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 visitor’s 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 visitor’s 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 SYSTEM’s 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 SYSTEM’s 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                                                     FUNCTIONAL REQUIREMENTS

  11.Remote Access Level Management
           a) Overview
      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                                                      FUNCTIONAL REQUIREMENTS

  12.Third Party Interfaces
           a) Overview
      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 SYSTEM’s IBM WebSphere Adapter shall provide a seamless, real time interface to
      IBM’s WebSphere Messaging System. This advanced feature shall leverage SYSTEM’s
      architecture for open connectivity with IBM’s WebSphere architecture for reliable
      messaging interfaces to deliver an advanced integration point between the two systems.
      SYSTEM’s 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 SYSTEM’s Microsoft Queues Adapter shall provide a seamless, real time interface
      to Microsoft Queues Messaging System. This advanced feature shall leverage
      SYSTEM’s architecture for open connectivity with Microsoft Queues architecture for
      reliable messaging interfaces to deliver an advanced integration point between the two
      systems. SYSTEM’s 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.   Pyrotronics MXL fire panel
                  2.   Pyrotronics MXL-IQ fire panel
                  3.   Notifier AM2020 fire panel
                  4.   Notifier NFS-640 fire panel
                  5.   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.   Zenitel AlphaCom
                  2.   Zenitel AlphaNet
                  3.   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                               •   Man Down
           •   Handheld 2 Button                               •   Man Down RF
           •   Handheld 4 Button                               •   Pendant
           •   Magnetic Contact                                •   Pendant, Dual Technology

                     LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                  Functional Specifications Version 6.3 Series                  Page 211
SECTION II                                                      FUNCTIONAL REQUIREMENTS

           •   PIR Detector                                     •   Wristband, Waterproof
           •   Spatial Position Detector                        •   Smoke Detector
           •   Universal Transmitter. 2
               Inputs
      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                                                      FUNCTIONAL REQUIREMENTS

           k) Central Station Alarm Receiver Interface
      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.   Bosch 6500/6600
                  2.   Digitized 3500/3505
                  3.   Osborne Hoffman OH-2000
                  4.   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                                                      FUNCTIONAL REQUIREMENTS

           m) Smart Card Life Cycle Management
      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 SYSTEM’s 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) user’s 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 SYSTEM’s 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 cardholder’s accessibility to locks and
      limit their access to areas without needing to update the locks. In the SYSTEM’s Alarm
      Monitoring application, the SYSTEM OPERATOR shall be able to assign authorizations
      to a cardholder’s 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 cardholder’s 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 XPP’s main menu.

      The SYSTEM shall support allowing the XPP operator to unlock a lock if that door’s
      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                                                    FUNCTIONAL REQUIREMENTS

  13.System Administration
           a) System Configuration
      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 Administrator’s 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                                                      FUNCTIONAL REQUIREMENTS

           j) 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:

              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 Operator’s 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 SYSTEM’s
      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.

              2.   Enable interaction between Physical Access Control Cardholders and
                   Windows logical domains. For example, if badge is lost, a designated
                   Windows account shall disable.

              3.   Control access to Computer Anti-Passback Areas

              4.   Issue Windows 2008/2003 Smart Card Logon and Smart Card User
                   certificates on the user's smart card.

                      LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                   Functional Specifications Version 6.3 Series               Page 225
SECTION II                                                     FUNCTIONAL REQUIREMENTS

                     1) Adding a New Account
              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
              cardholder’s 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
      day’s 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
      System’s 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                                                    FUNCTIONAL REQUIREMENTS

                    15) Alarm Acknowledgments Report
             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                                                    FUNCTIONAL REQUIREMENTS

                    25) All Events Over Time Report
             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 anti-
             passback 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 out-
             time 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                                                      FUNCTIONAL REQUIREMENTS

                    54) CCTV Instructions Report
             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                                                    FUNCTIONAL REQUIREMENTS

                    74) Hardware Panels Report
             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                                                      FUNCTIONAL REQUIREMENTS

                    105)     Receiver Accounts Report
             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                                                      FUNCTIONAL REQUIREMENTS

                    115)     User Transaction Log Report
             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 SYSTEM’s 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 cardholder’s 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 Operator’s 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 CUSTOMER’s 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                                                        FUNCTIONAL REQUIREMENTS

  14. Mobile Enterprise Applications
      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.   Access Control

              2.   Alarm Monitoring

              3.   ID Credential Management

              4.   Digital Video

              5.   Intrusion Detection

              6.   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                                                     FUNCTIONAL REQUIREMENTS

           PC Card slots: Two Type II or one Type III
           Temp Range: 32ºF to 122ºF (0ºC to 50ºC)
           Battery: Lithium Ion, Hot-Swappable
           Run time: 7 to 12 hours on two battery system
           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 holder’s 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                                                        FUNCTIONAL REQUIREMENTS

 Badge Layout Creation Module
  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 cardholder’s 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                                               FUNCTIONAL REQUIREMENTS

             Photo
                •     Border (Type, Width, Color)
                •     Fill Color and Style
                •     Ghost Factor
                •     Chromakey (Yes, No)
                •     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)
             Graphic
                •     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
                •     Bar-Code Format
                •     Border (Type, Width, Color)
                •     Fill Color and Style
                •     Object Positioning
                •     Rotation

             LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®            Functional Specifications Version 6.3 Series           Page 248
SECTION II                                                         FUNCTIONAL REQUIREMENTS

                          •     Encoded Information
                          •     Visibility (Yes, No)
                       Signature
                          •     Border (Type, Width, Color)
                          •     Fill Color and Style
                          •     Signature Color
                          •     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
                          •     Signature Pen Width
                          •     Chromakey
                          •     Object Visibility
                       Shape
                          •     Border (Type, Width, Color)
                          •     Fill Color and Style
                         •     Object Positioning
                         •     Visibility
           c) Bar-code Support
      The SYSTEM shall support the following bar codes as standard in the software:

           •   Code 3 of 9 (3:1)                                   •   Codabar
           •   Code 93                                             •   PostNet (Zip +4 Postal)
           •   UPCA                                                •   Code 3 of 9 (2:1)
           •   EAN 13                                              •   Interleaved 2 of 5 (2:1)
           •   EAN 8                                               •   Code 128 Auto
           •   Code 128 A                                          •   PDF-417 (2D)
           •   Code 128 B                                          •   UCC-128
           •   Code 128 C                                          •   MSI Plessey


                       LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                      Functional Specifications Version 6.3 Series                  Page 249
SECTION II                                                         FUNCTIONAL REQUIREMENTS

           •   Code 3 of 9 (3:1)                                  •   Extended Code 93
           •   Extended Code 3 of 9
           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 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. 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                                                       FUNCTIONAL REQUIREMENTS

           e) Object List
      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 object’s 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                                                         FUNCTIONAL REQUIREMENTS

  15. Screen Designer Tool
           a) SYSTEM Cardholder Standard Fields and Objects
      The SYSTEM shall support at a minimum the following standard fields for personnel
      information:

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

                  •   Scan ID                                          •     Replacement Value
                  •   Asset Name                                       •     Last Inspection
                  •   Acquired                                         •     Next Inspection
                  •   Replace                                          •     Record Last Changed
                  •   Type                                             •     Photo
                  •   Subtype                                          •     Photo Display
                  •   Serial Number                                          •   Last Reader
                  •   Department                                                 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                                       •   Extension
                 •   First Name                                      •   Last Changed
                 •   Middle Initial                                  •   Last Reader Accessed
                 •   Badge Type                                      •   Record Last Changed
                 •   Organization                                    •   Badge ID
                 •   Title                                           •   Issue Code
                 •   Address 1                                       •   Number of Prints
                 •   Address 2                                       •   Activation Date
                 •   City                                            •   Deactivation Date/Time
                 •   State                                           •   Badge Status
                 •   Zip Code                                        •   Photo
                 •   Office Phone                                    •   Photo Display
           d) SYSTEM Visit Standard Fields and Objects
                 •   Host Name                                           •   Actual Time In
                 •   Visitor Name                                        •   Actual Time Out
                 •   Status                                              •   Last Changed
                 •   Scheduled Time In                                   •   Type
                 •   Scheduled Time Out
                 •   Purpose
           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                                                      FUNCTIONAL REQUIREMENTS

           h) Field Styles
      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                                                        FUNCTIONAL REQUIREMENTS

           i) Field Alignment and Width Tools
      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                                                        FUNCTIONAL REQUIREMENTS

  16. Map Editor Module
      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)                         •   Macintosh PICT (.pct)
           •   Bitmaps (.bmp, .dib)                       •   Portable Network Graphics (.png)
           •   JPEG (.jpg)                                •   TIFF (.tif)
           •   JIFF (.jif)                                •   Windows Metafile (.wmf, .emf)
           •   Zsoft PCX/DCX (.pcx, .dcx)                 •   Targa (.tga)
           •   Adobe Photoshop (.psd)                     •   Kodak Photo CD (.pcd)
           •   CALS Raster (.cal)                         •   Kodak Flashpix (.fpx)
           •   GEM/Ventura IMG (.img)                     •   Encapsulated Post Script
                                                              (.eps)
           •   IBM IOCA (.ica)
           •   WordPerfect Raster (.wpg)
      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                                                        FUNCTIONAL REQUIREMENTS

  17. Import Module
  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)                       •   Macintosh PICT (.pct)
           •   JPEG (.jpg)                                •   Portable Network Graphics (.png)
           •   JIFF (.jif)                                •   TIFF (.tif)
           •   Zsoft PCX/DCX (.pcx, .dcx)                 •   Windows Metafile (.wmf, .emf)
           •   Adobe Photoshop (.psd)                     •   Targa (.tga)
           •   CALS Raster (.cal)                         •   Kodak Photo CD (.pcd)
           •   GEM/Ventura IMG (.img)                     •   Kodak Flashpix (.fpx)
           •   IBM IOCA (.ica)                            •   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                                                        FUNCTIONAL REQUIREMENTS

  18. DataExchange
  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 don’t 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 don’t 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                               PSD
                       CALS Raster                                       CAL
                       Delrina WinFax Group 3                            FAX
                       Delrina WinFax Group 4                            FAX
                       Encapsulated PostScript                           EPS
                       FAX Group 3                                       FAX
                       FAX Group 4                                       FAX
                       GEM Image                                         IMG
                       IOCA or IBM Image Object Content                  ICA
                       Architecture
                       JIFF or JPEG File Interchange Format          JPG/JIF
                       JPEG Tagged Interchange Format                    JTIF
                       Kodak FlashPix                                    FPX
                       Kodak PhotoCD                                     PCD
                       LEAD CMP                                          CMP
                       Macintosh Pict Format                             PCT
                       MacPaint                                          MAC
                       OS/2 Bitmap                                       BMP
                       Portable Network Graphics                         PNG
                       SUN Raster Format                                 RAS
                       Truevision TARGA                                  TGA
                       Microsoft Paint                                   MSP
                       Windows Bitmap                                    BMP
                       WordPerfect Format                                WPG
                       Zsoft PCX/Multipage PCX                      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                                                    FUNCTIONAL REQUIREMENTS

           c) Data Expressions
      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 doesn’t
             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 it’s deactivate date.




                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                 Functional Specifications Version 6.3 Series                 Page 261
SECTION II                                                    FUNCTIONAL REQUIREMENTS

           d) Import/Export Filters
      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                                                     FUNCTIONAL REQUIREMENTS

  19. SYSTEM Server Redundancy
  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                                                     FUNCTIONAL REQUIREMENTS

           f) Distributed Intelligence
      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                                                     FUNCTIONAL REQUIREMENTS

  20. DataConduIT

      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.

             2.   When a user’s 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 cardholder’s phone
                  number changes in the SYSTEM. The new phone number shall be
                  propagated through DataConduIT to the associated user account in the
                  company’s Active Directory.

             3.   When a cardholder’s access badge is disabled, DataConduIT shall
                  automatically disable that cardholder’s other IT user accounts.

             4.   Conversely when a user’s Windows or other Active Directory/LDAP
                  account is disabled, DataConduIT shall deactivate the cardholder’s
                  access badge in the SYSTEM.

             5.   A user’s Windows account for PCs in a research lab is normally
                  deactivated. When a cardholder cards into the research lab,
                  DataConduIT shall activate the user’s Windows account for the
                  computers in the research lab.

             6.   A 3rd party system acknowledgment of pending alarms in the
                  SYSTEM database.

      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 SYSTEM’s System Administration module.

                     LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®              Functional Specifications Version 6.3 Series                     Page 267
SECTION II                                                       FUNCTIONAL REQUIREMENTS

           a) SYSTEM API Toolkit Operations
                        1) Operations
              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)
                   2.   A badge is added or deleted, or its badge status changes
                   3.   A linked account is added or deleted
                        3) Hardware Events
              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

              2.   Date/Time – the date and time when the event occurred

                        LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                    Functional Specifications Version 6.3 Series                  Page 268
SECTION II                                                      FUNCTIONAL REQUIREMENTS

             3.   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                                                    FUNCTIONAL REQUIREMENTS

  21. Open Protocol Interface
     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 reader’s 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 non-
     proprietary 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                               WORKSTATION & PERIPHERAL REQUIREMENTS

A. Database Servers
  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 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 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
           Server Software
                 •   Microsoft Windows 2008/2003 Server 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 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
           Software
                 •    Microsoft Windows XP or Vista
                 •    Microsoft SQL Server 2005 Client License
                 •    SYSTEM Client Software for Windows XP or Vista




                      LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                   Functional Specifications Version 6.3 Series              Page 280
SECTION III                               WORKSTATION & PERIPHERAL REQUIREMENTS


C. Client Workstations Types
  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 cardholder’s record,
      with the exception of the cardholder’s photo. To edit the cardholder’s 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                              WORKSTATION & PERIPHERAL REQUIREMENTS

  5. Enrollment and Badging
     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                               WORKSTATION & PERIPHERAL REQUIREMENTS

  10. Visitor Management
      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                               WORKSTATION & PERIPHERAL REQUIREMENTS

D. Peripherals
  1. Video Camera
      The SYSTEM, when utilizing the credential management module of the SYSTEM, shall
      utilize a video camera to capture cardholder’s 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:                   NTSC
   Focal Length                     3.9mm ~ 63mm (126mm digital 2X)
   Aperture                         f1.6 to close
   Zoom Ratio                       16 X 1 actual
   Zoom Options                     Motorized, Remote
   Filter Size                      46 mm
   Lens Glass                       Color Corrected - Zero Aberration
   Iris Options                     Motorized or RS232 Control
   Iris                             Auto or Manual
   Focus                            Auto Focus or Manual
   Picture Element                  811 (H) X 494 (V)
   Resolution                       470 TV Lines
   Minimum Illumination             1 Lux at f1.2
   S/N Ratio                        Better than 48db
   AES                              1/60, 1/10,000 sec. (8 steps)
   BLC                              Digital Processor, Auto
   Neg/Pos                          Negative, Positive
   Gain Control                     AGC 8db~38db
   White Balance                    Auto: 2,600K-11,000K, Manual
   Power Source                     12V DC +/- 10%
   Dimensions                       62(W) X 62.2(H) X 102.2(D) mm
   DSP Control                      Programmable set up functions RS-232/RS-422
   Housing                          Die Cast Aluminum




                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                  Functional Specifications Version 6.3 Series               Page 284
SECTION III                                WORKSTATION & PERIPHERAL REQUIREMENTS

  2. Video Capture Board
      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 SYSTEM’s 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:       PCI
  Display:                       SVGA
  Inputs Accepted:               Composite and S-Video
  Flash Sync Capabilities:       Yes, integrated on the board
  Video Formats:                 NTSC and PAL
  Colors Supported:              Up to 16.7 million
  Video Memory:                  2MB DRAM
  Video Overlay:                 Yes
  Approvals:                     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                                WORKSTATION & PERIPHERAL REQUIREMENTS

  3. Direct Card Printer
     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:         672 dot wide, thin film
     Print Head Width:           56.9 mm
     Resolution:                 300 dpi
     Image Data:                 up to 8 bits per color
     Colors:                     Yellow, Magenta, Cyan, Black, Overlay
     Print Speed:                8 seconds per color
     Image Position on Media: better than 0.015”
     Processor:                  32-bit RISC processor
     Internal Memory:            4MB
     Frame Store:                948 x 672 pixels 24 bit color


                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                 Functional Specifications Version 6.3 Series                    Page 287
SECTION III                               WORKSTATION & PERIPHERAL REQUIREMENTS

     Cooling Mechanism:          Integral Fan, Air exhausted from the rear of the printer
     Input Range:                90-125 VAC, 180-265 VAC
     Frequency:                  47-63 Hz
     Load:                       200 Watts Max
     Approvals:                  UL, CSA, TUV
     Media:                      CR-80 credit card size, 2.125” x 3.375”
     Material:                   Gloss PVC Surface
     Thickness:                  0.015” - 0.063”
     Cassette Capacity:          100 to 500 cards
     Magnetic Encoder:           On-line encoding of Track 1, 2, and 3, hi-coercivity (4,000
                                 Oersteds)
     Operating Temperature:      5 to 40 degrees Celsius
     Storage Temperature:        -20 to +85 degrees Celsius




                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                  Functional Specifications Version 6.3 Series                  Page 288
SECTION III                              WORKSTATION & PERIPHERAL REQUIREMENTS

  4. Signature Capture Tablet
     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:                     2540 lpi/ 100 lpmm
     Accuracy (overall with pen):    +/- 0.5 mm (+/- .02 in.), maximum
     Pressure Levels:                256 Levels
     Maximum reading height:         5 mm (+/- .2 in.) or less
     Maximum Report Rate:            205 points per second
     Origin Position:                Upper left
     Communications Interface:    RS-232C
     Connector:                   9-Pin, D-sub, female
     Operating Temperature:       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):            5.04 x 3.78 inches
     Physical Size (W x D x H):      7.52 x 6.89 x 0.27 inches
     Cable Length:                   6.5 Feet
     Power Consumption:              1.2 Watt
     Weight:                         1 pound
     Power Supply:                   DC 12V, 200 mA
     Input Current:                  100 mA




                      LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                 Functional Specifications Version 6.3 Series                 Page 289
SECTION III                               WORKSTATION & PERIPHERAL REQUIREMENTS

  5. Report Printer
     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 100-
     sheet capacity and a microfine toner cartridge provided to produce quality black and
     white reports.

     The report printer shall have the minimum specifications:

     Resolution:                     300 dpi
     Resolution Technology:          Resolution Enhancement Technology and Microfine
                                     Toner
     Print Speed:                    4 pages per minute
     Languages:                      Enhanced HP PCL 5
     Memory:                         Standard: 1 MB
                                     Maximum: 2 MB
     Memory Technology:              Memory Enhancement Technology
     Media Capacity:                 100 sheets input, 50 sheets output
     Media Sizes:                    Letter, Legal, A4, Executive
     Media Types:                    Plain and Recyclable Papers, transparencies, and labels
                                     16-28 lb. Sheets
     Scalable Typefaces:             26 Intellifont
     Interfaces:                     Standard: HP Bi-Tronics Parallel
                                     Optional: HP JetDirect EX
     Warranty:                       One Year
     Dimensions:                     14.5” x 14.0” x 6.2”
     Weight:                         15.5 pounds




                    LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                 Functional Specifications Version 6.3 Series                   Page 290
SECTION III                                 WORKSTATION & PERIPHERAL REQUIREMENTS

  6. Event Printer
     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:                 9 Pin
     Print head width:                .34 mm
     Super Speed Draft:               435 CPS (12 CPI)
     Near Letter Quality:             75 CPS (10 CPI)
     Resident Scalable Fonts:         2 NLQ
     Okidata Standard Emulation:      Yes
     Automatic Paper Loading:         Yes
     Interface:                       Parallel
     Memory (Buffer) Size:            28K
     Noise Level Operating mode: 57 db
     Noise Level Quiet Mode:          55 db
     Warranty:                        One year
     Dimensions:                      15.7” x 13.6” x 4.6”
     Weight:                          15.4 pounds




                     LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                  Functional Specifications Version 6.3 Series                Page 291
SECTION III                                 WORKSTATION & PERIPHERAL REQUIREMENTS

  7. Modem
     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:               56 Kbps
     Universal Compatibility:         Yes
     Error Control:                   V.42/MNP 2-4 error control
     Data Compression:                V.42 bis/MNP5 data compression
     Approvals:                       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                             WORKSTATION & PERIPHERAL REQUIREMENTS

  8. Tape Backup System
     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.

     Remote Access Server Support:        Shall allow System Administrators to administer
                                          one or more servers from remote locations.

     SQL Server Support:                  Shall allow System Administrators to backup
                                          Microsoft SQL Server databases. These are the
                                          main files that shall be backed up.

     Scheduled/Unattended Backups:        Allows System Administrators to perform backups
                                          at pre-determined times. Intervals shall be in hourly,
                                          daily, weekly, and monthly intervals.




                   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 non-
                 volatile 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 manufacturer’s 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 32-
     bit 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 manufacturer’s 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                               ACCESS CONTROL FIELD HARDWARE DEVICES

  2. Input Control Module (ICM)
             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 lead-
     in 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.   UL 294, ULC, and CE Certified
                2.   12VDC Power


                     LENEL - A UTC FIRE & SECURITY COMPANY
OnGuard®                 Functional Specifications Version 6.3 Series                 Page 304
SECTION IV                                ACCESS CONTROL FIELD HARDWARE DEVICES

                 3.   Support for up to eight Magnetic and Wiegand Card formats
                 4.   Support for Clock/Data, Data1/Data0 Wiegand, F/2F, and Open
                      Supervised Device Protocol (OSDP) Communications
                 5.   1 Programmable Relay Output Per SRI
  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.   UL 294, ULC, and CE Certified
                 2.   12VDC or 24VDC Input Power
                 3.   Support for up to eight Magnetic and Wiegand Card formats
                 4.   Support for Clock/Data, Data1/Data0 Wiegand, F/2F, and Open
                      Supervised Device Protocol (OSDP) Communications
                 5.   2 Programmable Inputs and 2 Programmable Relay Outputs per
                      Reader
  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 LED’s 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                                       Phone: 585.248.9720
     Pittsford, New York 14534                                        Fax: 585.248.9185




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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:32
posted:10/7/2012
language:Latin
pages:326