INNER RANGE
SYSTEM SPECIFICATION
March 2010
SUBJECT TO CHANGE WITHOUT NOTICE. CHECK WEBSITE FOR LATEST REVISION.
www.innerrange.com
Disclaimer
(1) The manufacturer and/or its agents take no responsibility for any damage, financial
loss or injury caused to any equipment, property or person resulting from the correct
or incorrect use of this document.
(2) Whilst every effort has been made to ensure the accuracy of this manual, Inner Range
Pty Ltd assumes no responsibility or liability for any errors or omissions.
(3) Due to ongoing changes and development, the content of this document is subject to
changes without notice.
Please direct enquiries and comments regarding this document to:
Inner Range Pty. Ltd.
1 Millennium Court
Knoxfield 3180
Victoria, Australia
(03) 9753 3488
SUBJECT TO CHANGE WITHOUT NOTICE. CHECK WEBSITE FOR LATEST REVISION.
www.innerrange.com
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
2
Index
Section 1 - Software Spec ..................................................................................... 5
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
Computer Requirements................................................................................. 5
Architecture .................................................................................................. 7
Security ....................................................................................................... 9
Client Management ...................................................................................... 10
Interface With Field Hardware ....................................................................... 11
Programming .............................................................................................. 16
Virtual Panel ............................................................................................... 19
Software Database ...................................................................................... 20
Photo ID (optional module)........................................................................... 23
Card Pool (optional module) ......................................................................... 25
Schematics ................................................................................................. 26
DVR Integration (optional module) ................................................................ 28
Review ....................................................................................................... 30
Alarm Management ..................................................................................... 31
Communicator (optional module) .................................................................. 33
Dynamic User Import (optional module) ......................................................... 34
COM Interface (optional Module) ................................................................... 35
Basic Reports .............................................................................................. 36
Advanced Reports (optional module).............................................................. 37
Multi-Tenant ............................................................................................... 41
Operators ................................................................................................... 42
Section 2 - Hardware Spec ................................................................................. 43
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
General Requirements.................................................................................. 43
System LAN (Security Communications Network) ............................................ 45
Control Module ............................................................................................ 47
User Terminals ............................................................................................ 51
2x16 character LCD Terminal ........................................................................ 51
Weatherproof Terminals ............................................................................... 53
Touchscreen Terminals................................................................................. 55
Input / Output Expansion ............................................................................. 56
8 Input Zone Expansion Modules ................................................................... 57
16 or 32 Input Zone Expansion Modules ......................................................... 58
Wireless Detection ....................................................................................... 60
Door Controllers .......................................................................................... 62
Intelligent Four Door Controllers ................................................................... 66
Lift Controllers - Access Reader Interface ....................................................... 70
Lift Controllers - Lift Control Equipment Interface ............................................ 73
Power Supplies - Stand-alone ....................................................................... 75
Power Supplies -Intelligent (LAN Comms Capability) ........................................ 76
Analogue Input Monitoring............................................................................ 78
Dual-Format Proximity Reader ...................................................................... 80
Fibre Modems ............................................................................................. 81
BMS & HVAC Interpreter .............................................................................. 83
Hardware System LAN ................................................................................. 84
Section 3 - Functional Spec ................................................................................ 86
44.
45.
46.
47.
48.
49.
50.
51.
52.
General ...................................................................................................... 86
User Terminals ............................................................................................ 87
Weatherproof User Terminals ........................................................................ 89
Touchscreen User Terminals ......................................................................... 90
Real-time Clock and Calendar Functions ......................................................... 91
Database.................................................................................................... 93
User Database ............................................................................................ 95
Event Review Logging .................................................................................. 97
Remote Monitoring (Off-site communications) ................................................. 99
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
3
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
Alarm Monitoring System ........................................................................... 102
Input Testing ............................................................................................ 106
Duress Alarm Management ......................................................................... 108
Panic Alarm Management ........................................................................... 109
Door Access Control................................................................................... 112
Lift Access Control ..................................................................................... 117
Plant Monitoring System............................................................................. 119
Event Counting ......................................................................................... 122
Building Automation .................................................................................. 123
Zoned Air-conditioning Control .................................................................... 133
System Diagnostics ................................................................................... 134
Appendix A - Core Requirements ...................................................................... 137
64.
65.
66.
Software .................................................................................................. 137
Hardware ................................................................................................. 139
Functional ................................................................................................ 139
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
4
Section 1 - Software Spec
1.
Computer Requirements
1.1
Operating System
The software will function on various 32-bit and 64-bit Operating Systems,
including Microsoft® Windows® 7, Microsoft® Windows® Vista (Business or
Ultimate), Microsoft® Windows® XP Pro, Microsoft® Windows® 2000,
Windows 2000 Server and Windows 2003 server operating systems running
natively (i.e. not in a virtual machine environment). The server may require
User Account Control (UAC) to be disabled under Windows® Vista and 7 to
function correctly.
1.2
Minimum Server Hardware (small sites)
For sites with few Control Modules, no virtual users, no tenancies and low
traffic, the following system is recommended as a minimum:
(a)
2GHz single-core processor
(b)
1Gb RAM
(c)
CD-ROM (for software installation)
(d)
USB port for hardware protection dongle
(e)
Keyboard and mouse
(f)
300Mb of free hard disk space
(g)
Software:
1.
Windows® XP or Windows® Vista
2.
System Management Server Software
1.2.2
If client modules are installed on the same computer as the server (such as
for a laptop installation), then additional processing power, RAM and hard disk
space may be required.
1.3
Recommended Server Hardware (small to medium sites)
For sites running a modest number of Control Modules and/or few virtual
users and/or low event traffic, the following specifications are recommended:
(a)
2 GHz dual core processor
(b)
4GB RAM
(c)
CD-ROM (for software installation)
(d)
100Mbps network interface card
(e)
1 spare USB port for hardware protection dongle
(f)
Hard Disks: (faster Hard Disks deliver better performance)
(g)
1.
2 x 80GB hard disks for operating system and SQL log files
(RAID 1 Configuration)
2.
3 x 80GB hard disks for SQL data files (RAID 5 Configuration)
Software:
1.
Microsoft® Windows® 2003 Server
2.
Microsoft® SQL Server
3.
System Management Server Software
1.4
Recommended Server Hardware (large sites)
For sites running a large number of Control Modules and/or many virtual users
and/or high event traffic, two separate server computers are recommended:
1.4.1
Server Computer
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
5
(a)
2 GHz dual core processor
(b)
4GB RAM
(c)
CD / DVD Rom
(d)
Network Interface Cards:
1.
1 x 100 Mbps network interface card
2.
1 x 1,000 Mbps network interface card (gigabit Ethernet for
server to server communications)
(e)
1 spare USB port
(f)
Hard Disks:
1.
(g)
1.4.2
Software:
1.
Microsoft® Windows® Server 2003
2.
System Management Server Software
SQL Server Computer
(a)
Quad core processor (or 2 x dual core processors)
(b)
4GB RAM
(c)
CD / DVD Rom
(d)
Network Interface Cards:
(e)
(f)
1.5
2 x 10,400 RPM SCSI or SATA hard disks ( RAID 1
configuration)
1.
1 x 100Mbps Network Interface Card
2.
1 x 1,000 Mbps network interface card (gigabit Ethernet for
server to server communications)
Hard Disks:
1.
2 x 15,000 RPM SCSI or SAS Hard Disks (RAID 1
configuration)
2.
3 x 15,000 RPM SCSI or SAS Hard Disks (RAID 5
configuration)
Software:
1.
Microsoft® Windows® Server 2003
2.
Microsoft® SQL Server
Recommended Workstation Computers
(a)
2GHz single core processor
(b)
1Gb RAM
(c)
CD-ROM (for software installation)
(d)
1 x 100Mbps Network Interface Card (if running DVR integration)
(e)
500Mb of free hard disk space
(f)
XVGA video adapter supporting 1024x768 resolution and 32-bit colour
(g)
Audio speakers (if sound is required)
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
6
2.
Architecture
2.1
Client / Server
The software shall be implemented with a client / server architecture. Every
installation shall include exactly one ‘live’ server computer, which holds the
main system database. One or more computers can then run the client
software, which presents a user interface to users of the software.
2.2
Terminal Services, Citrix, Remote Desktop or related applications
The use of Terminal Services, Citrix, Remote Desktop or related applications
shall require the installation of an additional “Allow Remote” license key on the
server computer.
2.3
Multiple Control Module Connections
The system shall permit connections to multiple Control Modules
simultaneously. Control Modules can be connected using a variety of media
including serial, dial-up and TCP/IP.
2.4
IP Door Controllers
The system shall permit connections to IP Door Controllers. IP Door
Controllers can be connected at the same time as Concept 3000 and Access
4000 Control Modules.
2.5
Multiple Concurrent Logins
The system shall permit simultaneous connections from different Operators on
different workstations. Operators can be running the same or different
software modules on each workstation.
2.6
TCP/IP Networking
Clients can connect to the server over any TCP/IP network. No ‘file shares’ or
other network protocols will be required.
2.7
Automatic Refresh
The system will automatically refresh all workstations that are logged on.
2.7.1
If an event occurs in the field, it will be posted to all Operators
simultaneously.
2.7.2
If an Operator edits a programming item, any other Operator with the
information on-screen will see it change.
2.7.3
If an alarm is acknowledged, it will be removed from the pending alarms
window on all workstations.
2.8
Detect Two Operators Editing The Same Data
The system shall warn an Operator who simultaneously edits the same record
as another Operator. The system shall prompt the Operator whether to discard
or override the other Operators edits (subject to Operator permissions).
2.9
Operator Authentication
Operators must supply valid logon credentials before using any part of the
system.
2.10
Data Encryption
All information will be encrypted before being sent on any network. (See the
separate section on software security.)
2.11
Single Workstation Mode
The system can be installed on a single workstation if required.
2.12
Context Sensitive Help
Each module shall include comprehensive electronic help. Pressing F1 will
invoke context sensitive help for that screen. The help system will include
pictures, diagrams and explanations of how to use the system effectively.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
7
2.13
Field Hardware Independence
If the front-end software is not running, the field hardware will continue to
function at full capacity, including authentication of all users. No alarms,
tampers or security logging information is discarded, unless the field hardware
buffer becomes exhausted (up to 6,500 discrete events, depending on field
hardware configuration).
2.14
COM Programming Interface
The system shall support a COM programming interface so that programmers
of complementary building automation systems can access information stored
by the software such as database information and review. The system shall
implement encryption and passwords so that such a conduit is protected from
unauthorised access.
2.15
Dynamic User Import
The system shall support the dynamic importation of cardholder information
by monitoring a specified folder location for data files. When a data file is
discovered the cardholders are extracted and processed. The data file is then
automatically deleted.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
8
3.
Security
3.1
Encryption
3.1.1
Between Server and Clients
Communications between the front-end Server and front-end Clients will be
encrypted with Blowfish 128-bit encryption. Blowfish is a strong, publicly
documented symmetric block cipher designed in 1993 by Bruce Schneier.
There are no known attacks.
3.1.2
Between Server and Control Modules
Communications between the front-end Server and Control Modules shall be
encrypted with AES 128-bit encryption. AES is a strong, publicly documented
symmetric block cipher. There are no known attacks.
3.2
Hardware Lock
The system will require a USB hardware lock on the server computer. The
hardware lock contains all of the licensee’s credentials for running the
software. This can include trial licenses, paid licenses and optional extra
modules.
3.2.1
If the hardware lock is moved to a different computer, then the licenses shall
travel with it to the new computer.
3.3
Hacker Countermeasures
The USB hardware lock shall include critical security and communications
components to prevent hacking the system, and will be protected by a stateof-the-art security microchip.
3.4
Workstation Lockdown
The system shall be configurable to only permit client logons from designated
workstations.
3.4.1
Attempts to logon from unauthorised workstations will be logged and rejected.
3.4.2
The system will permit the security permissions of a workstation to be
arbitrarily restricted. The system will permit such restrictions to include:
(a)
Controlling which records are visible on that workstation.
(b)
Controlling which records can be opened for inspection on that
workstation.
(c)
Controlling which records can be modified on that workstation.
Such restrictions can be set for individual items such as users so that, for
example, a workstation could only see users 10-50, inspect users 12-25 and
edit users 15-20. Non-contiguous sets can be defined.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
9
4.
Client Management
4.1
Sites
The system will allow Operators to create any number of ‘sites’. Each site can
be programmed to reflect the name, geographic location and contact details of
the site. The system will allow free-form notes to be stored with each site (up
to about 20 pages per site).
4.1.1
Each site can have any number of Control Modules and field hardware.
Graphical maps and building blueprints can also be associated with each site.
4.1.2
Adding and Removing
Sites can be added and removed at any time, subject to Operator permissions.
When a site is added, removed or modified the changes update on all
workstations instantly.
4.1.3
Organisational Chart
Sites can be organised into hierarchies, much like an organisational chart.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
10
5.
Interface With Field Hardware
5.1
Supported Network Connections
The system will support a range of different connection types including:
(a)
TCP/IP Connections
The system will support TCP/IP connections via the Inner Range
Ethernet UART.
(b)
Direct Serial Connections
The system will support direct serial connections over RS-232 twisted
pair. Maximum recommended speed will be 38,400 baud (during
enrolment) and 9,600 baud (during normal operation).
(c)
Dial-up Connections
The system will support dial-up connections via any ATAPI compliant
modem (on the Server side) and an internal or external modem (on the
Control Module side). Maximum recommended speed will be 38,400
baud (during enrolment) and 9,600 baud (normal operation).
5.2
TCP/IP Connections Using IP Addressing and DNS
The system shall support the use of both IP Addressing and the Domain
Naming Service (DNS) to facilitate connections between Control Modules in
the field and the System Management Server.
5.3
Use of Domain Naming Service (DNS) for System Redundancy.
The system shall allow a selectable option to change the manner in which the
Field Hardware uses DNS. In this way, DNS or Dynamic DNS may optionally
be used in conjunction with a centralised database as a means of providing
additional system redundancy. This option will determine which of the
following modes are implemented on the particular Control Module:
(a)
The Ethernet UART on the Control Module will query the nominated DNS
Server upon start-up of the system or start-up of the programmed
communication task.
(b)
The Ethernet UART on the Control Module will query the nominated DNS
Server upon start-up of the system or start-up of the programmed
communication task and also within a few minutes of the system having
lost connection to the system management server. The DNS Server will
continue to be re-queried every few minutes whilst the system
management server is off-line until the connection has been restored.
5.4
Use of a Virtual Machine for System Redundancy
The system shall be capable of installation within a virtual machine
environment. In this way, the system load may be spread across multiple
computer hardware installations to give better performance and machine level
redundancy.
5.5
Permanent vs. On-Demand Connections
The system will support both ‘permanent’ and ‘on demand’ connections.
(a)
Permanent connections are always available for communications.
(b)
On demand connections are normally not kept open, but will be
established if an alarm occurs or to synchronise data or time between
the server and field hardware.
5.6
Network Path Redundancy
The system will support redundancy. If multiple connection paths are enabled,
then the system will choose the best available path.
5.6.1
If the current path fails, the system will switch to another path.
5.6.2
If the primary path becomes available, the system will switch back to it
automatically.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
11
5.7
Modem Blocking
The system will support modem blocking. With modem blocking, Operators
can specify which modems in a modem pool are available for dialling Control
Modules.
5.8
Connect To Multiple Panels
The system will allow Operators to connect to multiple Control Modules
simultaneously. (See the Architecture section for more information.)
5.9
Scheduled Connections
The system shall permit modem connections to be scheduled, either:
5.9.2
(a)
Hours, daily or weekly
(b)
On specific days of the week and at specific times
(c)
On a particular day of each month
(d)
On the first, second, third, fourth or last occurrence of a particular day
each month
Once a scheduled connection is made, the system can be programmed to
close the connection:
(a)
After a certain time has elapsed
(b)
After all offline edits have been synchronised
(c)
After no review has been received for a specified time interval
5.9.3
The system shall allow the number of retries, the retry timeout and the abort
interval to be specified for each schedule.
5.9.4
The system shall allow schedules to be configured on an individual panel basis.
5.9.5
The system shall maintain a log of successful connections as well as any errors
encountered in the process.
5.10
Control Module Enrolment
The system will require that Control Modules be enrolled into the system. This
enrolment process will be handled by a user-friendly enrolment wizard, which
guides the Operator through the enrolment process.
5.11
Support for Legacy Control Modules
The system will include support for legacy or older version Control Modules.
The degree of interoperability will be determined by the capability of the
version of Control Module connected and may extend to the:
(a)
Upload and Download of all structures
(b)
Control of Areas, Doors etc.
(c)
Retrieval and storage of Review
5.12
Control Module Import / Export
The system will allow Operators to export a Control Module configuration to a
file. The exported file, which will be saved in XML (Extensible Mark-up
Language) format, will include a complete snapshot of that Control Module
including module programming, cardholders, area programming, extended
fields and notes.
5.13
Enrol From Template
The system will allow Control Modules to be enrolled from a template instead
of an actual Control Module on the network. This will allow Operators to
“program up” a system prior to hardware procurement.
5.13.1
The system will include templates for all Control Module memory
configurations. Operators will be allowed to create any number of additional
templates based on Control Modules installed at their site.
5.14
Support for a second temporary System Management Software
Connection
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
12
In addition to support for multiple Client Workstations, the system shall allow
one additional and concurrent computer connection directly to the Control
Module to facilitate installation and servicing of the system by the Installer or
Service Technician. Such a secondary connection will be ad-hoc and temporary
in nature. The Operator(s) of the primary System Management application will
be alerted to any programming changes that are made during this secondary
session and will be given the opportunity to accept or reject the programming
changes.
5.15
Software  Control Module Interface
5.15.1
Octane™ Compression
The software shall support Octane™ compression on all communications paths
with Control Modules. (This technology radically improves communication
bandwidth by compressing data in both directions. Octane™ is based on a
technology which yields significant performance gains on installed systems. )
The table below shows typical enrolment timings both with and without
Octane™ compression on defaulted Control Modules.
Configuration
Size
Standard
Access
Enlarged
Apartments
Access 2
Special
Alarms
512k
512k
512k
512k
512k
512k
512k
Without
Octane™
10:10
10:48
8:41
9:01
10:37
10:18
10:58
With Octane™
Speed Increase
2:13
2:39
1:26
1:20
1:34
1:28
1:28
459%
408%
606%
676%
678%
702%
748%
Source: Panel Enrolment Timings, Andy Lam (engineer), Inner Range 2004.
5.15.2
Rijndael AES 128-bit Encryption
Communications between the front-end Server and Control Modules will be
encrypted with Rijndael AES 128-bit encryption. Rijndael is a strong, publicly
documented symmetric block cipher designed by Dr. Joan Daemen and Dr.
Vincent Rijmen, and has been the AES (Advanced Encryption Standard)
algorithm since October 2000. There are no known attacks.
5.15.3
International Standard 32-bit CRC
Communications between the software and Control Modules will be verified
with the international standard 32-bit cyclic-redundancy check polynomial.
5.15.4
Native TCP/IP Support
The system will support native TCP/IP communications with Control Modules
fitted with an Ethernet UART Board. The software shall communicate with
Control Modules on the same network or different networks, including Control
Modules located elsewhere on the worldwide Internet.
5.15.5
Native PPP Support
The system shall include PPP support. This means that the Control Module can
connect to the internet through a regular dial-up ISP, and communicate with
the software through this connection.
5.15.6
Alarm Prioritisation
The Control Module will transmit alarm events to the software in priority to
regular review events.
5.15.7
Status Prioritisation
The system shall prioritise ‘status’ events over regular review events. This will
ensure that graphical floor plans are updated quickly regardless of the amount
of buffered review.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
13
5.15.8
The system shall prioritise ‘control’ events over regular review events. This will
ensure that control commands are actioned quickly, regardless of the amount
of buffered review.
5.15.9
Status notifications will not rely on polling. Changes shall be transmitted by
the Control Module as they occur and at no other time.
5.15.10
Remote Hardware Control
The system will allow Operators to remotely control field hardware. The
following items will be controllable:
(a)
Areas and Area Lists (with tamper option)
(b)
Auxiliaries, Home Auxiliaries and Auxiliary Lists (with override option)
(c)
Doors and Door Lists (with timed option)
(d)
Floors and Floor Lists (with override option)
(e)
Zone Inputs and System Inputs (with sticky option)
5.15.11
Push Programming
The system shall send programming changes through to field hardware
without any special LAN commands such as LAN Init or LAN Secure. Field
hardware will adopt the new programming immediately and automatically.
5.15.12
Data Integrity Check
At any time an Operator can perform a full or partial data integrity check. This
will compare the field programming with the front-end programming. Any
differences will be highlighted and the Operator can decide how to synchronise
each difference.
5.15.13
Monitoring Field Programming Changes
On connection to the Control Module the system shall automatically detect if
any system parameters have been changed at a terminal. The system will
notify the Operator which item(s) were changed. The Operator can choose to
accept or reject the changes.
5.15.14
LAN Status
The system shall display the status of all field hardware automatically. The
status displayed will include:
5.15.15
5.15.16
(a)
Module present
(b)
Module missing
(c)
Module substituted
(d)
Module not installed
Control Module Initiated Connections
The system shall be configurable so that the Control Module initiates a
connection with the front-end software. A connection can be triggered by the
following events:
1.
An alarm or tamper has occurred
2.
Review buffer has filled to a specified watermark
Timed Fax Bypass
The system will support timed fax bypass, so that the Control Module can
share a single dial-up line with a facsimile machine.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
14
5.15.17
Synchronise Date/Time
The system shall be configurable to automatically synchronise the date and
time of each Control Module. Synchronisation settings will be separate for
each Control Module. Synchronisation can be scheduled to run:
(a)
Hourly, daily or weekly
(b)
On specific days of the week and at specific times
(c)
On a particular day of each month
(d)
On the first, second, third, fourth or last occurrence of a particular day
each month
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
15
6.
Programming
6.1
Programming GUI
The system will include a graphical user interface that adheres to the Microsoft
User Interface Guidelines for Windows Professional Editions.
6.1.1
The system will provide forms tailored for each editing task.
6.1.2
Multiple forms can be opened at the same time.
6.1.3
Having a form open will not prevent the Operator from performing any other
editing tasks.
6.2
Context-Sensitive Help
The system will provide comprehensive on-line help, with full indexing and
search capabilities.
6.2.1
The Operator can invoke help specific to the current screen or window by
pressing the F1 key.
6.3
Field Device Programming
The system will allow Operators to program or re-program field devices either
live or off-line.
6.3.1
Programming changes made to field device programming will take effect
automatically, without requiring a LAN initialisation command.
6.4
Online and Offline Editing
The system will allow both online and offline editing.
6.4.1
All offline edits will be tagged, so that an Operator can immediately see which
data items have been modified but not saved to the field hardware.
6.4.2
The system will include a counter, visible at all times, of how many modified
records are waiting to be sent to an offline Control Module and its attached
field hardware.
6.4.3
The system will enable Operators to immediately hide all records that are
synchronised, so that only offline edits are visible.
6.4.4
Online edits will be sent to the field hardware immediately.
6.4.5
Programming changes made to the panel at the terminal are automatically
updated to the system management software.
6.5
Filtering
The system will display items according to criteria specified by the Operator.
With a single button press, the Operator can selectively show or hide items
based on:
(a)
Name (text search)
(b)
LAN status (secured, missing, substituted, not installed)
(c)
Programming status (programmed, un-programmed, queued for
upload/download)
6.6
Installer and Master PIN Protection
As an additional safeguard, the PIN of User 0001 (‘installer’) and User 0002
(‘master’) shall never be displayed. To change these PINs, the existing PIN
must be entered first.
6.7
PIN Discovered Warning
If an Operator edits a cardholder PIN from the front-end, and inadvertently
discovers the PIN of another cardholder, then the following sequence will
occur:
(a)
The Operator shall be told that the PIN cannot be used.
(b)
When the cardholder with the discovered PIN accesses an Elite
Terminal, they shall be warned that their PIN has been discovered.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
16
6.8
Cardholder Expiry Scheduling
Operators can schedule the expiry of any cardholder in the system. When the
appointed date and time occurs, the cardholders’ user type will automatically
change to the specified type.
6.8.1
Normally, this will be the user type ‘none’ which expires the user; however,
any user type can be specified, meaning that at a scheduled time a user’s
access privileges can be increased or decreased as required.
6.8.2
This mechanism shall be implemented within the front-end software, and will
be provided in addition to the existing expiry mechanism in the Control
Module.
6.9
Direct Cardholder Enrolment
The system will allow Operators to enrol cardholders directly into the front-end
software via an attached card reader. The following reader hardware will be
supported:
6.9.1
(a)
Inner Range Card Enrolment Station
(b)
Inner Range Reader
(c)
ACS Smart Reader
(d)
HID PC Log-On
The following formats will be supported:


N-Bit
37 Bit


General
36 Bit


IR 40 Bit
35 Bit


40 Bit
34 Bit

32 Bit


30 Bit
27 Bit
IR Card Enrolment Station
IR Card Reader
ACS Smart Reader
HID PC Log-On
26 Bit
Site Code Method






27 Bit
30 Bit
32 Bit
34 Bit
35 Bit
36 Bit
37 Bit
40 Bit
IR 40 Bit
General
N-Bit
IR Card Enrolment Station
IR Card Reader
ACS Smart Reader
HID PC Log-On
26 Bit
Direct Entry Method




















6.10
Full and Partial Upload and Download
The system will allow full and partial upload and download between the frontend and Control Modules.
6.10.1
If the Control Module is offline, then the affected records are visibly tagged to
remind the Operator that the upload or download will occur the next time the
Control Module is online.
6.11
Dynamic Memory Configuration Changes
The system will automatically detect if a Control Module is defaulted with a
new memory configuration. It will automatically adjust the front-end database
accordingly, and give the option of expanding or truncating the number of
items in the directory as required.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
17
6.12
6.12.1
Commissioning Reports
The system will allow Operators to generate a variety of Commissioning
Reports, including:
(a)
User programming
(b)
User Type programming
(c)
Input programming
(d)
Door List programming
(e)
Lift Car List programming
(f)
Floor List programming
(g)
Siren List programming
It will also allow Operators to generate a variety of Cross Reference Reports,
including:
(a)
(b)
(c)
User Type Reports
1.
Which doors can be accessed by this User Type
2.
Which users are of this User Type
3.
Which areas can be controlled by this User Type
4.
Which floors can be accessed by this User Type
Area Reports
1.
Which inputs are in this area
2.
Which inputs in this area that can generate alarms
3.
Which users can turn this area on
4.
Which users can turn this area off
5.
A list of inputs in an area and their process groups
User Reports
1.
Which users can access a door
2.
Which users can access an area
3.
Which users can access a floor
4.
Which doors a user has access to
5.
Which areas a user can control
6.
Which floors a user has access to
6.12.2
Reports can be viewed, printed to hard copy or saved to file.
6.12.3
Filtering
The system shall permit commissioning reports to be filtered for criterion such
as names, notes or regular expressions. Filtering may require an Advanced
Reports license.
6.13
Complete Audit Trail
The system will maintain an audit trail of all programming changes made from
the front-end. The audit trail will include the transaction date and time, details
of the transactions, and the operator logged on.
6.14
Site Cross-Reference
At any time an Operator will be able to generate a “relationships tree” which
shows how all programming items inter-relate. For example, clicking on a door
will show the lock auxiliary, access group, inter-lock group and controlled
areas for that door.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
18
7.
Virtual Panel
7.1
Group Multiple Panels
The system will allow Operators to create one or more virtual panels. A virtual
panel will be a ‘container’ for one or more physical Control Modules. Items in
the virtual panel shall be editable as per normal, except changes will be sent
automatically to all member Control Modules.
7.1.1
Any number of Control Modules can be combined into a virtual panel.
7.1.2
Control Modules can be added and removed from the virtual panel at any
time.
7.2
Virtual Panel Wizard
The system shall guide Operators through the process of creating a virtual
panel with a user-friendly wizard. The wizard will ask the Operator which
panels to include in the virtual panel, and also how the virtual users should be
created. Choices will include:
(a)
Default all users
(b)
Import users from a member panel
(c)
Don’t create any virtual users (the Operator can add them manually
later)
7.3
Virtual Cardholders
Operators can open cardholders in the virtual panel. Any changes will
automatically be saved to all physical member panels. The virtual cardholder
will include the extended information (such as photograph, name and address,
and notes) and also any custom user fields that have been defined in the
system.
7.3.1
Virtual cardholders can have the same user type in each member panel, or
different user types. The system will provide complete flexibility in assigning
user privileges in each panel, whilst maintaining the ability to edit the
cardholder in one place.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
19
8.
Software Database
8.1
Standard Query Language (SQL)
The system will store all information in a relational database. The database
will be an industry-standard database composed of tables and relationships
and accessed with SQL queries. The system databases shall, as a minimum,
be compatible with SQL Server 2005.
8.2
Open Database Connectivity (ODBC)
The server will access the database engine via an industry-standard ODBC
connection.
8.3
Referential Integrity
The database will support referential integrity.
8.4
Maximum Limits
The system shall use ODBC and SQL to access a relational database, hence
there will be no hard limits on the number of cardholders, field devices or
security data that can be stored. The choice of database engine will dictate the
actual maximum limits.
8.4.1
The default engine installed will be SQL Express Server. This is a database
engine based on the popular SQL Enterprise Server. SQL Express Server
imposes a database limit of 4 gigabytes, or approximately four thousand
million bytes.
8.4.2
A computer with the recommended hardware configuration will comfortably
store hundreds of thousands of cardholders and manage events from multiple
Control Modules in the field.
8.4.3
The system shall be capable of being hosted by SQL 2008 Server.
8.5
Users (Cardholders) Database
The system will store information about users of the system. A user is a
person with privileges at the field hardware level – in other words, a person
with PIN or card access at a system terminal or card reader.
8.6
Control Module Data
The system will store a complete copy of all Control Module data including
User Type, User Rank, Extra Area, Extra Door, Extra Door List, Access
Options, Expiry Data and Fob Programming.
8.7
Extended Information
The system will store extended information that, due to space limitations, isn’t
stored by field devices. This information will include:
(a)
Title, First and Last Names (as separate long fields; the field hardware
will store a single name field for some or all cardholders, depending on
memory configuration)
(b)
Birth date, Gender
(c)
Business Profile (Position / Department / Email, Phone / Fax / Mobile)
(d)
Personal Profile (Address, Email, Phone / Fax / Mobile)
(e)
User Photograph
(f)
Notes (free text)
(g)
Custom fields (up to 32 custom labels, with each storing free text)
8.8
User Presets
The system will allow the Operator to define preset files containing default
field values that can be applied to a User with the click of a button.
8.9
Exporting User Information
The system will allow the export of single or multiple user records. This may
also be used to assist an Operator in the creation of User preset files or a
better understanding of the User data Import feature.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
20
8.10
Importing User Information
The system will allow extended information to be imported from an external
source, such as a payroll database.
8.11
User Photographs
The system will allow a user photograph to be stored with each user. (The
photographs are stored in the database along with the other user fields so that
photographs are included in the normal system backup procedure.)
8.12
Automatic Photo Pop-Up
The system can be configured to pop-up a user’s photograph in response to a
definable event occurring (for example, if the user badges at a particular
reader).
8.12.1
The system shall support, via a licensed option, a more advanced user pop-up
window that is always on top of other windows and can be resized or
maximised to full screen. The advanced user pop-up will retain a history of at
least 100 accesses, and allow Operators to navigate backwards and forwards
through the history.
8.13
Windows Image Capture
The system will allow Operators to capture user photographs directly from
WIA-compliant imaging device such as digital cameras, web cams and
scanners.
8.14
Database Backups
The system will provide a backup tool that can completely archive a snapshot
of the database. The snapshot will be stored in a space-efficient, compressed
archive. The system will provide a straightforward mechanism to restore a
previous backup. Only operators with the highest security privileges will be
permitted to restore from a backup.
8.14.1
Custom Backups
The system shall allow backups to be customised. For example: “Backup only
programming data”, or, “Backup programming data and review.”
8.14.2
Scheduled Backups
The system can be configured to automatically backup the database. Backups
can be scheduled to run:
(a)
Hourly, daily or weekly
(b)
On specific days of the week and at specific times
(c)
On a particular day of each month
(d)
On the first, second, third, fourth or last occurrence of a particular day
each month
8.14.3
Custom Scheduled Backups
The system shall allow multiple scheduled backups to be configured. For
example: “Backup just the programming data every day, but review data only
once per week.”
8.14.4
Single Click Backups
The system will provide a single-click backup solution if Operators want to
manually create a backup. Restoring from a backup will be equally
straightforward.
8.14.5
Backup Scope
The backup process will duplicate all data including module programming,
cardholders, extended fields, custom fields, user photos, floor plans, report
templates and review data. In the event that an entire software installation is
completely wiped, including all data files, then restoring via the backup utility
will recover the system 100%. All that will be required is the licensing dongle
(or a replacement), the software installation CD and the backup file.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
21
8.15
Purge Review To External Archive
The system will allow Operators with sufficient privileges to permanently
“move” aged review data from the software’s main database to an archive file.
Operators will still be able to examine archived review from within the review
manager module. The system will also allow review archives to be purged
from the system.
8.15.1
Archive Segments
The system will allow review to be archived into segments of 1, 2, 3, 4, 6, or
12 months.
8.15.2
Scheduled Purging
The system will allow scheduled purging of review from old archives.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
22
9.
Photo ID (optional module)
9.1
Custom Cards
The system will allow Operators to define custom ID cards using a graphical
user interface.
9.1.1
The system will support the design and printing of double-sided ID cards.
9.1.2
The PhotoID user interface will include a range of photo editing tools, as a
minimum:
9.1.3
9.2
(a)
Copy, cut and paste
(b)
Crop and Zoom
(c)
Move to Back, Front, backwards and forwards
(d)
Rotation and/or cropping of User images as they are acquired either
from a camera or a file.
Each Photo object shall allow the operator to alter its properties, including:
(a)
Image source, orientation and dimensions
(b)
Border size, shape, colour, thickness and visibility
Default Card Properties
The system will allow Operators to define default card properties for all new
card designs that are created. These properties shall include:
(a)
The dimensions of the card
(b)
The default font to be used
(c)
The date format
(d)
Resolution
(e)
Units of measure in inches, millimetres or points
9.3
Card Design Objects
The system will allow Operators to design custom ID Cards by firstly assigning
a colour and optional gradient to each side of their card design template.
9.3.1
Operators will be able to add a range of images, text and data fields through
the incorporation of object placeholders on their card design template. These
objects will as a minimum include:
9.4
(a)
User Photos from the system database
(b)
Any fixed User field from the system database
(c)
Any Custom User field from the system database
(d)
Any free text
(e)
Any compatible image file (bmp, gif, jpg, emf, png), such as company
logos etc
(f)
Barcodes
Card Design Object Properties
The system will allow Operators to alter an extensive range of properties for
each Card Design Object, the extent and scope of such alterations to be
determined by the exact nature of the object, but such properties will include:
(a)
Source and dimensions
(b)
Font size, type and colour
(c)
Border visibility, colour and thickness
(d)
Object fill colour and transparency
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
23
9.5
Card Design Templates
The system will allow Operators to save their custom card designs as Card
Design Templates so that their designs may be saved and reused on multiple
occasions.
9.5.1
The system will allow card templates to be imported and exported and
exchanged between system server installations.
9.5.2
The system will allow these Card Design Templates to be stored centrally in
the database on the system computer server and backed up as part of the
normal system backup procedure.
9.6
Card Associations
The system will allow the Operator to define one or more associations between
specific Users and Card Design Templates. These associations will be based
values stored for each User in the nominated existing User field. It will also be
possible to use a custom User field which has been set aside by the Operator,
specifically for this purpose.
9.7
Card Preview with User Data
The System will allow the Operator to preview the Card Design Template with
User data. The Operator will be allowed to preview the card with any User
record in any panel, providing their Operator permissions also allow them
access to view the selected data.
9.7.1
Should Card Associations be enabled and configured, previewing cards with
User data will automatically cause the correct Card Design Template to be
displayed for the selected User record.
9.8
Card Printing
The system will allow Operators to print ID badges by selecting a card
template and one or more users.
9.8.1
The system will allow single or batch print runs to generate ID badges.
9.8.2
The system will allow front side only, back side only or both front and back
sides to be printed for either a single card or a batch of cards.
9.8.3
Should Card Associations be enabled and configured, printing cards will
automatically cause the correct Card Design Template to be printed for each
selected User record.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
24











N-Bit
40 Bit


General
37 Bit


IR 40 Bit
36 Bit
Direct Entry Method
Site Code Method
35 Bit
Supports Multiple Formats
The system will support card pools with the following formats:
34 Bit
10.2
32 Bit
Manage Multiple Card Pools
The system will support multiple direct entry and site code card pools. Pools
of the same type can be merged by dragging one pool onto another.
30 Bit
10.1
27 Bit
Card Pool (optional module)
26 Bit
10.






10.2.1
The type of card used will be specified per card pool.
10.3
Track Card Status
The system will report the status of each card as: available, assigned, lost or
suspended. Double-clicking on a card shall display details of how the card is
assigned within the system.
10.4
Tag Cards
The system will allow operators to quickly tag cards as lost or suspended. Lost
and suspended cards can be reactivated at a later date by an operator with
sufficient privileges, or returned to the card pool for subsequent re-issue.
10.5
Automatically Create Card Pools
Operators will be able to automatically scan all Control Modules, and create
direct entry and site code card pools based on existing panel programming.
10.6
Detect Non-Pooled Cards
The system will allow operators to scan panels for assigned cards that don’t
exist in any card pool, and will enable operators to quickly distribute any such
cards to the card pool(s) designated by the operator.
10.7
Moving Cards
The system shall allow cards to be moved from one pool to another.
10.8
Adaptive User Rotation Module
The system shall support numbers of cards than can be stored in the on-board
control module database, such that, if a card is read and that card is not
found, then the panel will query the system management software to find a
match. If found, the panel will automatically download the user programming
for that card. This allows for far greater card numbers to be supported than
what the panel can store locally.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
25
11.
Schematics
11.1
Importing Maps
The system will allow Operators to import maps in a variety of image formats,
including:
(a)
JPEG (Joint Photographic Experts Group) Files
(b)
BMP (Windows Bitmap Picture) Files
(c)
TIFF (Tagged Information File Format) Files
(d)
PNG (Portable Network Graphics) Files
11.1.1
Once imported, blueprints shall be scalable to any arbitrary size, or
automatically zoomed to fit the screen size.
11.2
Drill-Downs
The system will allow Operators to create drill-downs. Drill-downs are
navigational hotspots that switch between different maps or blueprints. For
example, there might be several buildings on a campus map. Clicking a
building could open a blueprint for that building. Clicking the stairwell could
switch to the first floor.
11.2.1
Drill-downs are represented as translucent shapes. It will be up to the
Operator to decide what shape to use – almost any shape can be constructed.
11.2.2
Any number of drill-downs can be placed on a map. Drill-downs can be moved
or deleted at any time.
11.3
Live Status Monitoring
The system will allow the status of field hardware to be monitored in real time.
The field hardware guarantees that status changes will be dispatched
immediately, regardless of how many regular review events are buffered for
sending.
11.4
The following field hardware can be added to a floor plan:
(a)
Areas (on / off / alarm / tamper)
(b)
Inputs (sealed / in alarm / in tamper / had alarm or tamper; isolated /
restored)
(c)
Auxiliaries (on or off; override / no override)
(d)
Home Auxiliaries (on or off)
(e)
Doors (locked or unlocked)
(f)
Lift floors (free or secure)
11.5
Control Field Hardware
The system will permit operators with sufficient privileges to control field
hardware directly from floor plans using either interactive Icons or traced
shapes.
11.5.1
Control requests will be posted immediately, and the new status of the item
will appear on all floor plan terminals automatically.
11.6
Default Icons
The system will be installed with a library of default Icons for use on maps or
blueprints. These icons can be associated with particular objects within the
system and, when placed on a schematics map or blueprint, will allow the
operator to view the real time status of that object or to click on the Icon to
control the associated object one the field hardware.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
26
11.7
Customisable Icons
The system will allow the operator to define a custom library of Icons from
existing image files. These Icons may then be used on a map or blueprint to
indicate the status of the associated object. In this way, a general “Auxiliary
Output” may have an Icon that more accurately depicts its actual function,
such as a fan or a water pump.
11.8
Animated Gif Icons
The system will allow the operator to define Animated Gif Icons as part of the
Custom Icon Library. In this way, a schematics map or blueprint may be used
to show the realistic movement of a system object as it changes state, such as
the swinging of a door as it opens and closes, thus presenting a more intuitive
and interesting graphical interface for the system operators to use.
11.9
Area Trace Tool
The system will let Operators create areas of any shape. The following shapes
are examples of shapes that can be defined:
11.10
Zone Area Tool
The system will let Operators create arbitrary shapes, and assign the shape to
an Input. This lets the system designer represent motion sensors, beam
detectors and other “shape oriented” sensors.
11.11
Alarm Group Tool
The system will let Operators group inputs together and display them on the
map as a single icon. If any inputs in the group go into tamper or alarm, the
icon goes into tamper or alarm. The Operator can then open the icon and get
a list of which inputs have triggered the condition. Inputs may be from
different Control Modules and different areas.
11.12
Automatic Floor-Plan Pop-up
The system can be programmed to display a particular floor plan in response
to a programmed event.
11.13
Mimic Panel
Because areas and zones can be assigned to arbitrary shapes on a floor plan,
the system can easily be set-up to emulate a mimic panel.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
27
12.
DVR Integration (optional module)
The system will provide true integration with a range of Digital Video
Recorders. Operators will be able to view live and recorded camera images
directly within the software. Operators can control PTZ cameras including pan,
tilt, zoom and iris. Operators will be able to issue commands directly to
cameras and DVRs.
12.1
Attach DVRs and Cameras
Operators will be able to enrol multiple DVRs.
12.1.1
DVRs will be addressable via serial and/or TCP/IP network connections
(depending on the model of DVR used).
12.2
Supported Models
The following brands and models will be supported as a minimum:
(a)
Baxall RS485 BaxNet
(b)
Baxall Vivid Range of DVRs
(c)
Dedicated Micros Digital Sprite 2
(d)
Dedicated Micros Digital Sprite 2 (rev. a)
(e)
Dedicated Micros DVIP
(f)
Dedicated Micros SD DVRs
(g)
Pacom PDR 16
(h)
Tibet
(i)
Tibet Magic Radar
(j)
March Networks DVRs
(k)
Dallmeier DIS and Leonardo DVRs
(l)
Mitsubishi DVRs
(m)
Panasonic DVRs
Note that different cameras from different DVRs of different brands can be
displayed collectively and mixed in any combination.
12.3
Software Video Multiplexing
The system will allow up to 16 cameras to be multiplexed onto a single, timesynchronised window. The layout can be changed at any time. Any number of
separate multiplexed windows can be displayed, with each showing footage
from the same or different cameras and DVRs.
12.4
Synchronise Date/Time
The system can be configured to automatically synchronise the date and time
of each DVR. Synchronisation settings are separate for each DVR.
Synchronisation can be scheduled to run:
12.4.1
(a)
Hourly, daily or weekly
(b)
On specific days of the week and at specific times
(c)
On a particular day of each month
(d)
On the first, second, third, fourth or last occurrence of a particular day
each month
Operators will be able to synchronise manually if they wish.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
28
12.5
Remotely Control PTZ Cameras
The system will allow operators to remotely control any PTZ cameras. This
includes pan, tilt, zoom, focus and iris. If a camera has stored PTZ camera
presets (pre-saved combinations of the above parameters) then Operators will
be able to activate these presets from within the software.
12.6
Associate Cameras with System Objects
The system will allow operators to associate one of more cameras with specific
objects in the security and access control system. These objects will include:
(a)
An Input
(b)
An Area
(c)
An Auxiliary
(d)
A Door
(e)
A User
(f)
A Lift Car
(g)
An LCD Terminal
12.7
Locate Footage Based On Review And Alarm Notification
The system will allow operators to synchronise video playback based
Associated Cameras and a review event. In other words, the software will
display what the associated cameras recorded at the time a review event was
generated. Operators will be able to freeze-frame or seek forwards/backwards
near the event, as per normal DVR operation.
12.8
Floor Plan Integration
The system shall allow operators to place cameras onto site floor plans.
Operators will be able to view camera footage by clicking on that camera.
12.9
Footage Playback Control
Operators will be able to apply all the normal DVR operations to recorded
footage, including forward/reverse play, freeze frame, cue/review and single
frame advance (both forward and backward). All cameras in the same
multiplexer view will remain synchronised at all times. Different multiplexer
windows have their own playback controls, which will operate independently.
12.10
On-Screen Display (OSD)
The system will optionally superimpose an On-Screen Display for each camera
in a video window. The OSD will show the name of the camera.
12.11
Triggers
The system will allow operators to define complicated triggers, which can be
based on any combination of review events, alarms or special conditions.
When the event triggers, the system can be programmed to switch to a
particular camera and display live footage.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
29
13.
Review
13.1
Automatic Review Archiving
The system will automatically maintain an archive of all review events for all
Control Modules enrolled in the system. Each Control Module will buffer review
while a front-end connection is not active.
13.1.1
The system will ensure that any buffered events will be fetched the next time
a connection is active with the Control Module. While a connection is active,
each Control Module will dispatch review events as soon as they occur.
13.2
Software Audit Trail
The system will maintain an audit trail of front-end software operations. This
audit trail will be viewed and archived with field hardware review. The system
will record the date and time of each transaction along with the name of the
Operator logged on.
13.3
Review Event “Go To” Link
The system will allow Operators to right-click on a Review event and, by
making a further Menu selection, go to either the User, Door or Area record
that is stipulated within that specific Review event.
13.4
Colour Coded Review Display
The system will provide colour coded Review entries to allow easy distinction
between Review event types. Operators will be allowed to edit the colour of
each Review event type or reset them back to the default colours.
13.5
Advanced Review Filtering
The system will allow Operators to build complex review filters. Filters can be
created by adding simple filters to a review window and stacking them
together to form more complicated filters. Each filter can specify a particular
item of text or data to match against.
13.5.1
Individual filters and filter stacks can be modified at any time. They can also
be saved to disk and loaded later on.
13.6
Live and Offline Review
The system will allow searching/filtering of both live and offline (archived)
review.
13.7
Unlimited Review Windows
The system will let the Operator create as many review windows as desired.
Each window can have a different set of filters applied.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
30
14.
Alarm Management
14.1
Alarm Sound Cues
The system will let Operators configure what sounds are played by the
software when an XMIT alarm appears in a review window, and (as a separate
setting) when an alarm restore appears in a review window. The options will
include:
14.2
(a)
Beep PC speaker
(b)
Play a sound file (either from library or custom)
Custom Alarm Events
The system will let Operators trigger alarms based on complex filters. The
custom alarm will support the following configuration options:
(a)
Alarm processing level
(b)
Requires operator response (yes or no)
(c)
Custom text message
(d)
Custom text colour and background colour
(e)
Beep PC speaker
(f)
Play a sound file (either from library or custom)
(g)
Make the Review module full-screen
(h)
Flash the Review module in the Windows® task bar
(i)
Perform Server Action Lists
14.2.2
Server Action Lists
The system shall allow one or more Server Action Lists to automatically run in
the event of an alarm. Actions that can be performed include, but are not
limited to, controlling Auxiliary Outputs, Area On/Off, User Access, and
External Communications (ie to another panel, or monitoring station).
14.2.3
User Selectable Alarm Levels
The system will allow Operators to attach an alarm level to each alarm. The
supported alarm levels will be low, medium, high and critical. Active alarms
will be grouped by priority level.
14.2.4
Customisable Alarm Procedures
The system will support customised alarm procedures. Alarm procedures are
procedural notes that guide Operators through the process of investigating
and managing an alarm. The system will allow any number of alarm
procedures to be created. Each response can include multi-line text with full
per-character text formatting.
14.3
Third Party Integration
The system shall be capable of receiving text data from third party systems or
devices, and integrating it into its alarm management procedures. For
example, an intercom system may be integrated with the security system,
such that, when a button is pressed on one of the intercom units an alarm
may be raised in the security system and video surveillance of the related
area may be activated.
14.4
Alarm Acknowledgement
The system can require Operator acknowledgement of an alarm if its
processing options are set accordingly.
14.4.1
When an alarm is acknowledged at one workstation, it will be automatically
removed from the alarm window of all workstations.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
31
14.4.2
Custom Acknowledgement Window
Operators will be able to customise the acknowledgement window for each
alarm event by specifying which fields are included. The options will include:
(a)
Message box – if enabled, a message will pop up on the Operator’s
screen
(b)
User information – if enabled, the user’s photograph will pop up when
the Operator responds to the alarm
(c)
Auto pop-up – if enabled, the user’s photograph will pop up when the
alarm is received
(d)
Start review – if enabled, a review window will open so the Operator can
gain context on the alarm
(e)
Start schematic – if enabled, the specified building floor plan is opened
so the Operator can see the alarm
(f)
Print report – if enabled, will print a specified report
14.5
User Activity Window
The system will provide, via a licensed option, the ability to view a user
activity window. The window will display user photographs, in real time, as
users access doors in the field.
14.5.1
The user activity window will be a resizable window with a “picture log” of
users that have accessed a specified area. The centre picture will be displayed
at maximum size with event details (date, time, user name) displayed
underneath. To either side, small thumbnails of the preceding and succeeding
users will be displayed.
14.5.2
Operators will be able scroll backwards and forwards through the list of user
photos.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
32
15.
Communicator (optional module)
The system shall allow, via an optional module, messages to be conveyed over
a variety of electronic communications in response to defined event triggers.
15.1
15.2
15.3
15.4
Communications Paths
The system shall permit messages to be sent over the following media:
(a)
Email
(b)
SMS
(c)
Pager
Plug-ins
The system will provide plug-in support for additional media types that can
add functionality to the software. The following plug-ins shall be supported
initially:
(a)
Sound plug-in – the system can play a sound in response to an event
(b)
ComText plug-in - for sending ASCII commands to peripheral devices or
systems
Message Templates
The system will allow Message Templates to be defined, which specify
(a)
Where to send a message (any of the communications paths can be
selected, including those supported by plug-ins).
(b)
For each path, the text that will be sent in the message. Messages can
include information from the review message that triggered it.
Message Rules
The system will allow Message Rules to be defined, which specify
(a)
A regular expression for matching review messages
(b)
An optional regular expression for excluding messages
(c)
A template that will be ‘executed’ if a review message satisfies (a) and
(b) above, which determines the text and transmission paths of what
Communicator dispatches
(d)
A message priority from 0 to 100 (100 is highest)
(e)
Recipients to receive the message
15.5
Operation
Communicator shall monitor live review from Control Modules, and wait for
messages that match any of the Message Rules.
15.5.1
When a Message Rule matches, Communicator will queue the text in the
Message Template with the priority in the Message Rule on the
communications paths in the Message Template. This will occur for each
recipient in the Message Rule.
15.5.2
High priority messages will be dispatched before low priority messages.
15.6
Custom Messages
The system shall permit Operators to queue custom text messages with
custom priorities. The messages can be queued on any of the supported media
types.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
33
16.
Dynamic User Import (optional module)
The system shall provide a mechanism to automatically enrol users based on
an output file from a Property Management System. This Dynamic User
Import module must as a Windows® service.
16.1
Interface
The Dynamic User Import Module interface shall indicate if it is idle,
processing a setup file or processing records via an icon.
16.2
Import File
The system shall allow CSV files, Windows INI files, or DUI files as the source
of the user records.
16.3
Pre-Processing
The system will allow pre-processing of import data through the use of a batch
file.
16.4
Operation
The system shall monitor a nominated folder for compatible Dynamic User
Import Module files (CSV, Windows INI, or DUI format). If a file is discovered,
the file is processed for any users that it contains and then deleted.
16.4.1
Processing each user will mean creating the user, assigning the fields from the
Dynamic User Import Module file to the user (or blanking fields if directed)
and adding the user to a card pool if configured to do so.
16.4.2
If the user already exists then the record is modified. Commands in the import
file can also specify users to be deleted.
16.4.3
The system shall allow users to be added, modified or deleted from multiple
Control Modules, with separate user offsets in each Control Module.
16.5
Virtual Panels
The system shall allow users to be added, modified or deleted from Virtual
Panels.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
34
17.
COM Interface (optional Module)
The system shall provide a library based interface to enable software
developers to write software that can interact directly with the system
management software. This interface will allow high level integration to a wide
variety of software applications and intelligent systems such as human
resource database applications, booking systems, student record systems,
complex video surveillance systems and building management systems.
17.1
Interface to Query the Names of Areas, Doors, Users, and User Types
The system shall provide an interface to enable third party software
developers to write software that can connect to a computer server and query
the names of Areas, Doors, Users and User Types within each Control Module.
17.2
Interface to Query Areas Doors Users and User Types
The system shall provide an interface to enable third party software
developers to write software that can receive live or archival review from the
computer server.
17.3
Interface to Add, Modify or Delete Users
The system shall provide an interface to enable third party software
developers to write software which can add, modify or delete Users within the
system management software.
17.4
Interface to be Protected
The system shall ensure that any interface it offers for the purposes of
allowing high level integration to other software systems is comprehensively
protected through the use of authentication and encryption.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
35
18.
Basic Reports
18.1
Pre-defined Report Templates
The system will provide seven pre-defined report templates: all events, all
alarms, XMIT alarms, user access, door access, lift access, time on site (if
licensed as an option) and filtered events.
18.2
User-definable Criteria
Each report will prompt the Operator for any criteria needed to run the report
such as reporting interval, Control Modules to report on, doors involved and
target users.
18.3
Filtered Reports
The system will allow a report to be generated based on a filtered data set. In
other words, if an Operator creates a review window and attaches filters to the
window, then the report will only include data entries that satisfy the filters.
18.4
Exporting Reports
Once generated, reports can be exported as formatted HTML or unformatted
text. Reports can be printed at any time.
18.5
Programming Reports
The system will allow operators to view, print or export to file a range of
reports related to system programming. Operators will be able to generate the
following reports:
(a)
User programming
(b)
User type programming
(c)
Input programming
(d)
A list of users for each user type
(e)
A list of inputs in each area
(f)
A list of reportable inputs per area
(g)
A list of users with access per door
(h)
Users who can turn an area on
(i)
Users who can turn an area off
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
36
19.
Advanced Reports (optional module)
19.1
Muster Reports
The system will allow Operators to generate muster reports summarising user
activity over the preceding 24 hours from the report date. Built-in templates
will permit muster reports grouped by access point, by area, by date or
ungrouped (sorted by time only). Operators will be able to create their own
muster reports using the report editor.
19.1.1
Operators will be able to specify which areas to run the muster report against,
and can also optionally select muster points which will be highlighted in the
muster report.
19.1.2
Operators will be able to save common reporting options as a custom report
for easy access later on.
19.2
User and Activity Reports
The system will allow Operators to create a variety of reports based upon the
User data and photos stored in the system database. This information may be
further filtered based upon the Review activity of the Users.
19.2.1
The system will allow Operators to easily create filters and reporting criteria
for use with their reports. Intuitive criteria “Bracketing” or “Grouping” function
will allow Operators to create and apply even the most complex of reporting
filters.
19.2.2
The system will allow Operators to name and save their report designs under
custom folders for ease of access.
19.3
Card Pool Reports
The system will allow Operators to create a variety of Card Pool reports to
assist in the management of cards. These reports may also be qualified by
Review activity to identify which cards have been used through specific Doors
etc.
19.4
Exception Reports
The system will allow Operators to create a variety of Exception Reports,
detailing which Users or cards have NOT been used in the system or have NOT
accessed a particular Door or Area in the past day or week or month etc.
19.5
First or Last Event Reports
The system will allow Operators to create a variety of reports that display the
First event or Last event only for each User or Card during a particular
reporting period.
19.6
Time On Site Reports
The system will allow generation of time on site reports.
19.6.1
Customisable Report Criteria
The system will allow the start and end date and time to be specified.
19.6.2
(a)
One or more shifts can be defined per report.
(b)
The resolution of all date/time fields will be 1 second.
(c)
The Operator must select at least one cardholder and door. Any number
of additional doors and cardholders can be specified, across multiple
Control Modules if required.
Selectable Reporting Fields
The Operator can select any of the following fields for inclusion in the Time On
Site report:
(a)
Access Points
(b)
Access Counts
(c)
First In
(d)
Last Out
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
37
19.6.3
(e)
Total Time
(f)
Time On Site
(g)
Time Off Site
(h)
Shift Count
(i)
Shift Misses
(j)
Exception
Detailed vs. Exception Reporting Modes
The Operator can choose a Detailed Report, which includes all Time On Site
information, or an Exception Report.
(a)
The Exception Report only includes entries that match specified
exception criteria, such as minimum or maximum hours per day / week
/ month.
19.6.4
Customisable Shift Tolerance
The Operator can specify a shift tolerance. In and Out events occurring near
the start or end of a shift will be included if within the specified tolerance.
19.6.5
Customisable Worker Breaks
The Operator can specify that time off site is not included if it is shorter than a
specified time interval. For example, if this value is set to 10 minutes and a
user has an out event at 10:30am which is followed by an in event at
10:35am then the 5 minutes the user was off site will not be included in the
calculations.
19.6.6
Output to CSV File
A Time On Site report can be output to a Comma Separated Values (CSV) file
readable by Excel® and other software.
(a)
19.6.7
Output to MYOB File
A Time On Site report can be output to a MYOB® (Mind Your Own Business)
file.
(a)
19.6.8
19.6.10
The report data will include employee code, item code, quantity (as
calculated by the report) and rate
Custom Data Export Format
A Time On Site report can be output in a format specified by the Operator.
(a)
19.6.9
The Operator can choose which fields are included, and in what order.
The Custom Data Export options allow the Operator to specify the fields
and write the format and syntax of the data string that will exported.
Report Validation Triggers
The system will automatically flag users whose report data may include
inaccuracies. Users are flagged who trigger any of the following events:
(a)
Two or more consecutive ‘Door Out’ events without an intervening ‘Door
In’ event.
(b)
Two or more consecutive ‘Door In’ events without an intervening ‘Door
Out’ event.
(c)
First event in shift is ‘Door Out’.
(d)
Last event in shift is ‘Door In’.
(e)
No ‘Door Out’ events in shift.
(f)
No User/Door Access review entries.
Save and Load Report Settings
The system will allow all settings to be saved to a Time On Site report
template, which can be re-used at a later time.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
38
19.7
Report Designer
The system will include a fully featured report designer that can edit existing
report templates or create brand new templates. The report designer will allow
operators to:
(a)
Place coloured and formatted text and graphics on a report
(b)
Place data fields onto a report, including user photographs
(c)
Add drawing shapes and symbols
(d)
Place charts on a report based on live reporting data
(e)
Add barcodes to a report
(f)
Place tables on a report of tabular data grouped by arbitrary datum
(g)
Add forms to a report
(h)
Place runtime data from other applications using industry-standard OLE
container objects
19.7.1
The report designer will be WYSIWIG (what you see is what you get), meaning
operators will be able to drag objects onto the report and see a visual preview
of how the report will look when generated.
19.8
Organise Reports
The system will allow operators to organise reports into customised groups, so
that related reports are accessible in a single location. The system will allow
operators to save commonly used report settings (such as a selection of areas
for a muster report, or export settings for an extended user report) for quick
and easy access at a later stage.
19.8.1
Saved reports will be easily accessible, and can be generated with just a few
mouse clicks.
19.8.2
Saved reports can be grouped into custom categories designated by the
operator.
19.9
Time and Panel Event Based Scheduling of Reports
The system will allow any one or more Advanced Reports to be run on either a
time or panel event based schedule.
19.10
Export / Import of Report Definitions
The system will allow the Operator to save and reload the definition of a report
for the purposes of sharing the design and framework of the report between
Customer Support personnel and Operators on other similar systems without
having to send them confidential user data.
19.11
Report Definitions Saved on the Computer Server
The system will allow report definitions to be stored centrally on the computer
server so that they are preserved as part of the system backup procedure and
all Operators on all Workstations can potentially make use of the report
definitions.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
39
19.12
Output Formats
The system will allow operators to output a report to a file in the following
formats:
Format
Description
HTML
Hypertext Markup Language
PDF
Portable Document Format
RTF
Rich Text Format
MHTML
MIME Hypertext Markup Language
XML
Extensible Markup Language
JPEG
Joint Photographic Expert Group picture
EMF
Microsoft® Enhanced Metafile
BMP
Windows Bitmap picture
TIFF
Tag Image File Format picture
Multi-TIFF
Multiple Tag Image File Format picture
XLS
Microsoft® Excel® Spreadsheet
TTY
Teletype dot-matrix format
TXT
Text
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
40
20.
Multi-Tenant
20.1
Unlimited Number of Tenants
The system will support any number of tenants in a system.
20.2
Universal Tenanting
The system will permit any item to be assigned to tenants. This includes
areas, doors, cardholders, auxiliaries, zones, modules and all other
programming items; and also front-end entities like floor-plans, sites and
workstations.
20.2.1
When an Operator logs on, their tenant list will be loaded by the system and
used as a filter to determine what items the Operator can or cannot see.
20.2.2
Items that aren’t tenanted will be visible to ALL Operators.
20.2.3
Items can be placed in more than one tenancy.
20.2.4
An Operator can see an item if they share a tenancy in common with that
item, or if the item is not in any tenancy.
20.3
Tenancy Area Counting
The system shall provide tenancy area counting. Instead of counting against
an area for every entry, count values can be achieved through tenancy area
counting. This is useful, for example, in a scenario of a shared car-park,
where only 20 “Tenant 4” cars are allowed to enter, despite there being other
free spaces allocated to other tenants.
20.4
Review
The system will ensure that Operators only see review messages and receive
alarm events that pertain to their tenancy or tenancies.
20.5
Tenancy Counting Review
The system shall provide real-time review of tenancy counting. When a count
increments/decrements this event will be instantly displayed in review.
20.6
Sharing Items Between Tenancies
The system will allow entities to be shared between tenants. For example, if a
reception is shared between two offices, then the areas, doors, inputs and
auxiliaries associated with the reception are visible to both tenants. Items not
in a common area will only be visible to the respective tenants.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
41
21.
Operators
21.1
Operator Types
The system will support multiple Operator Types. Each Operator Type fully
defines the level of access permitted by Operators of that type.
21.1.1
Operators can be assigned an unlimited number of Operator Types. They will
inherit the combination of permissions granted by each individual Operator
Type.
21.2
Operator Permissions
Permissions can be applied to specific items. For example, an operator might
have the ‘see’, ‘inspect’ and ‘change’ permissions for doors 1-5 and 20, but
only the ‘see’ and ‘inspect’ permission on all other doors.
21.3
(a)
See. Without this permission, the item is invisible to the Operator.
(b)
Inspect. Without this permission, the Operator cannot open the item
for inspection.
(c)
Change. Without this permission, the Operator cannot save changes to
the item.
(d)
Create. Without this permission, the Operator cannot create new
instances of the item.
(e)
Delete. Without this permission, the Operator cannot delete the item.
(f)
Control (field hardware only). Without this permission, the Operator
cannot control the field hardware item.
(g)
Print. Without this permission, the Operator cannot print the item.
(h)
Export. Without this permission, the Operator cannot export the item to
a file.
(i)
Set Permissions. Without this permission, the Operator cannot modify
the permissions of the item for themselves or other Operators.
Operator Access Parameters
The system will allow authorised operators to define access parameters for
other operators, governing the times and dates at which each operator is
permitted access to the system management software. The parameters that
can be specified will include:
(a)
Expiry Date and Time. The date and time at which the operator’s
access to the system will be revoked.
(b)
Start Date and Time. The date and time at which the operator’s
access to the system will commence.
(c)
Access Times. The days of the week and the period of time during the
day that the operator’s access to the system will be permitted.
21.4
Workstation Permissions
The system can be configured to only permit Operator logons from designated
workstations.
21.4.1
Attempts to logon from an illegal workstation will be logged and rejected.
21.4.2
Operator permissions can be applied to a workstation. When used in this way,
they set the MAXIMUM permissions for that workstation. Operators with
greater privileges will have those privileges truncated whilst using that
workstation.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
42
Section 2 - Hardware Spec
22.
General Requirements
22.1
Integration
The system shall be a single integrated access control and alarm monitoring
system. The system shall also provide integrated control of lighting, heating,
ventilation, air-conditioning and other custom applications as required.
22.2
Host PC
The system must provide an option for connection to a host PC, however full
system functionality must be maintained with or without the Host PC
connected.
22.3
Supply of Equipment
Each item of equipment supplied shall be a standard product of an
established, reputable manufacturer. Custom hardware and/or custom
operating firmware will not be acceptable.
22.4
Modular Design
The system shall be of a modular hardware design allowing for detection and
control devices to be connected to system modules within their immediate
vicinity and also providing for expansion and modification of the system to
meet future requirements.
22.5
LAN
Modules shall communicate via a secure, monitored LAN system utilising a
communications format that does not compromise system integrity.
22.5.1
The LAN shall provide for a minimum of 1500 metres of LAN cabling and/or 64
remote modules to be installed without requiring additional hardware. LAN
Isolation/Repeater equipment shall be available to allow LAN cabling distances
to be extended up to 6.0km on twisted pair cable and/or up to 10km on
Optical Fibre.
22.6
Cabinets/Tamper Protection
All field equipment shall be fitted with cabinet tamper detection capable of
detecting any attempt to remove the cover and any attempt to remove the
enclosure from its mounting surface. Optical tamper devices will not suffice.
22.7
Input Wiring
Alarm monitoring inputs shall be wired using dual end-of-line resistors
installed at the detection device such that the system can monitor Seal, Alarm
(Un-seal), Open Circuit (Tamper) and Short Circuit (Tamper) states.
22.7.1
Each detection device shall be connected to a separate Zone Input for
individual monitoring and reporting unless otherwise stated.
22.7.2
The system shall allow Detection devices with Normally Closed or Normally
Open outputs to be wired to general purpose Zone Inputs in the same
manner. A programming option shall be provided for each Input to define
whether the device connected utilises Normally Closed or Normally Open
outputs. The default setting shall cater for Normally Closed outputs.
22.8
Power Supply
22.8.1
AC Mains Supply Voltage
All field equipment powered from the AC mains supply shall operate on a
supply of 240V AC +/-10%. (Terminal voltage at input to Transformer or Plug
pack)
22.8.2
DC Supply Voltage
All field equipment powered from the system LAN or a separate DC power
supply shall operate on a nominal supply of 12V DC. Normal operation shall
be maintained over a supply range of 11V to 14V DC.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
43
22.8.3
Surge Protection
Optional low voltage AC and battery surge protection devices shall be available
that provide superior protection against damage from electrical transients
such as lightning and power surges.
22.8.4
Batteries
All field equipment powered from the AC Mains supply shall incorporate a
dedicated connection for a re-chargeable Sealed Lead Acid battery of at least
6.5 AH capacity and up to 17 AH capacity to provide backup power in the
event of Mains supply failure.
22.8.5
The equipment shall provide a suitable circuit to charge the batteries during
normal operation.
22.8.6
Battery Testing
An Automatic Battery Testing procedure shall be provided with a
programmable start time that allows the battery test sequence to commence
daily / weekly / monthly / annually [As required]
22.8.7
Programming options shall be provided to allow any field equipment with a
dedicated backup battery connection to be included in an Automatic Battery
Test procedure with a test time specified separately for each Module to be
tested. (Allowing for variations in the load current of each Module.)
22.8.8
Battery Test times for each Module shall be programmable up to 255 minutes
in 1-minute intervals.
22.8.9
Battery Testing shall only be active on one Module at any time.
22.8.10
A battery test currently running on a module shall automatically be cancelled if
any of the following events occurs:
(a)
An AC failure on that Module
(b)
Sirens are activated on that Module
(c)
A LAN comms failure on that Module
(d)
A Low Battery Alarm on that Module
(e)
The Installer accesses the Power Test menu
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
44
23.
System LAN (Security Communications Network)
Communications between the Control Module and remote Modules shall be via
a dedicated Local Area Network (LAN).
23.1
Cable Types
The LAN shall operate reliably over the following cable types:
(a)
Category 5 cable.
(b)
RS485 / RS422 Twisted pair data cable.
23.2
Data Rate
LAN communications shall operate at 19,200 baud (bps).
23.3
LAN Data Security
An option for a LAN Encryption key shall be provided and will not require any
additional hardware or special firmware to be installed. Enabling encryption
shall cause the Control Module to generate a random encryption key that is
immediately broadcast to all remote Modules. If a Module is powered down,
its record of the current encryption key will be erased. The system shall be
capable of logging and reporting individual “Module substitution” alarms
should any Module attempt to communicate without the current encryption
key.
23.4
LAN Supervision
The Control Module shall continuously monitor all remote Modules for Off-line
condition via a supervisory time report system. The system shall provide for a
report time of 1 to 255 seconds to be programmed for each individual Module
according to the level of supervision required. The system shall record all
communications errors for each separate Module. The installer shall have the
ability to view and reset the error count.
23.4.1
Should any Module fail to communicate with the Control Module, a “Module
Off-line” alarm shall be generated that identifies the specific Module. The
alarm shall be logged and annunciate locally and/or to a remote central
monitoring station as required.
23.5
LAN Fail Report Hold-off
If the LAN is significantly damaged, a large number of LAN failure alarms and
restores may be reported, potentially flooding the Central Station with
continuous alarms and restores.
23.5.1
The Control Module shall offer a LAN Hold-off feature which, when enabled,
will restrict the number of LAN Fail input alarm/restore cycles to 4 within an
approximate 2 hour period. After 4 cycles have been reached, any more
processing of the LAN Fail input is temporarily “masked”. Every 2 hours from
the last LAN Fail input alarm, the counter will be cleared and the LAN Fail input
will be “unmasked”, enabling another 4 LAN Fail input alarm/restore cycles
over the next 2 hour period. LAN “Timeout”, “Lost”, “Substitution” and
“Recovered” Review events will still be logged for the masked inputs.
23.5.2
The Control Module shall allow the Installer to manually unmask any masked
LAN Fail inputs when the cause of the LAN Fail alarms has been rectified.
23.6
LAN Cabling Distance
The LAN shall be able to support up to 2000 metres of LAN cabling and/or 64
remote Modules using the specified cable without requiring additional
transmission equipment. Remote Modules shall be capable of communicating
on a single "daisy-chained" cable run of up to 1500 metres from the Control
Module.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
45
23.7
LAN Expansion
Optional LAN Isolator/Repeater devices shall be available to expand the LAN
cabling distance and/or the number of Modules supported up to a maximum of
250 Modules. These devices shall allow remote Modules to be installed up to
6.0km from the Control Module using the specified cable.
23.8
LAN Isolation
Optional LAN Isolator/Repeater devices shall be available to provide improved
surge protection through segmentation of the LAN and the elimination of earth
loops as required in larger installations and multi-building sites. The devices
shall provide a minimum of 2.5kV isolation between each section of the LAN
connected to the device.
23.9
Surge Protection
Optional LAN surge protection devices shall be available that provide superior
protection against damage from electrical transients such as lightning and
power surges.
23.10
Monitored Loop Option
Optional LAN Isolator/Repeater devices shall be available to enable the entire
LAN or sections of the LAN to be wired in a monitored loop configuration of up
1500 metres.
(a)
If a single break in the loop occurs, communication shall be maintained
to all Modules in the loop.
(b)
If two or more breaks in the loop occur, communication shall be
maintained to all Modules except those between the breaks.
23.10.2
Each LAN Isolator device shall provide “LAN Loop Fail” and “LAN Branch Fail”
alarm outputs.
23.11
Optical Fibre
Optional RS485-Optical Fibre Modem pairs shall be available to allow
transmission of the LAN over Optical Fibre. These devices shall allow remote
Modules to be installed up to 10km from the Control Module.
23.11.1
Configuration options on the Fibre Modem shall provide a simple setup method
to define whether the modem is located at the Controller end or remote end of
the fibre link.
23.11.2
Product variants shall allow for the use of Single-mode or Multi-mode fibre.
23.11.3
The Fibre Modem design shall allow the Fibre network to be configured in
Daisy Chain, Star or Loop architectures.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
46
24.
Control Module
24.1
Design
The System Control Module shall be a dedicated microprocessor based module
with dynamic and non-volatile memory and upgradeable built-in operating
firmware.
24.2
Power Supply
The Control Module shall be powered by16V to 18V AC from an approved
Transformer or Plug pack supplied with the Module. The module shall include
an on-board 13.8V DC power supply, battery charger and connection for a 12V
Sealed Lead Acid backup battery of at least 6.5 AH and up to 17 AH capacity.
24.3
Communications
The Control Module shall maintain communications with all other Modules
connected to the system LAN and shall be capable of reporting alarms and
system activity to one or more Central Monitoring Stations.
24.4
Telephone Line Interface
The Control Module shall include an on-board telephone line connection
suitable for PSTN (dialler) or Private Line (Leased Line) connection. The
system shall have the appropriate Telecommunications authority approvals for
connection to the PSTN network.
24.5
PSTN Surge Protection Devices
Optional PSTN surge protection devices shall be available that provide superior
protection against damage from electrical transients such as lightning and
power surges.
24.6
RS232 Interface
The Control Module shall be capable of providing up to 4 bi-directional serial
RS232 Ports for connections to serial communications devices. Programming
options shall provide for these Ports to be connected to any of the following
devices:
(a)
The System Management Software
(b)
Upload / Download Installer’s Programming Utility
(c)
External Modem for use with System Management Software or
Installer’s Programming Utility software.
(d)
Automation systems
(e)
Serial Printer.
(f)
Securitel STU. (Australia only)
(g)
External PSTN Modem.
(h)
GSM Module (e.g. FE2000 GSM Module, FE3000 Serial GSM Module,
FE3000 Multi-path IP STU)
(i)
C&K SpreadNet® Wireless Receiver. (See Note 1 below)
(j)
Data Multiplexer (Contact distributor for details of products supported)
(k)
Elevator Management System (Contact distributor for details of
protocols supported)
(l)
Clipsal C-Bus Network
(m)
Inovonics FA-400 Wireless Receiver and MF Receiver (See Note 2 below)
(n)
PosData 4 Channel Model BX Digital Video Recorder (Allows users to
control, access and program the DVR via a LCD Terminal).
(o)
Dynalite Dynet Network
(p)
The following home automation / building automation systems:
© 2007 Inner Range Pty. Ltd.
(e.g. 3rd party custom building automation
software and compatible Serial Devices, etc).
Rev. 7.6 (v4.2.1/v7.6)
March 2010
47
1.
AMX
2.
Crestron
(q)
IR-Transtech BMS (Building Management System) and HVAC interface
(r)
HPM iControl network
(s)
Pacom RTU
Note 1: C&K SpreadNet® Wireless Receiver. Only relevant in countries
where SpreadNet® has the appropriate communications authority approvals,
e.g. United States, Canada, Russia and South America. Check with local
distributor of C&K Systems products for other countries.
Note 2: For applications in other countries outside Australia and United States,
please check with Inovonics or their local distributors for appropriate
communication authority approvals.
24.7
Host Computer
The Control Module shall be capable of connecting to a Host Computer via a
direct RS232 connection, a PSTN line connection or an Ethernet TCP/IP
connection. The host computer shall be able to provide full database
maintenance, monitoring and control of the system.
24.7.1
When an Ethernet TCP/IP connection is used, the Control Module shall be
capable of connecting to the Ethernet network directly via a plug-on Expander
Board without employing any external micro serial server, terminal server or
similar device.
24.7.2
The plug-on Expander Board shall include a standard Ethernet connector for
easy connection and shall be compatible with commonly available 10BaseT
Ethernet networks. The plug-on Expander Board shall also provide up to 3 bidirectional serial RS232 communications ports for the Control Module to
interface with external serial devices or systems.
24.7.3
The Control Module shall provide a means of supervising the integrity of both
serial RS232 and Ethernet connections to the System Management Host
Computer. This may be achieved by use of either a dedicated system input or
by nominating a “problem” input which will be placed automatically in the
Alarm state whenever the relevant connection has been lost and will restore
when the connection is once again available.
24.7.4
A separate External PSTN Modem shall be able to be connected to the Control
Module via the plug-on expander board to support dial-in connections from the
Host Computer when the on-board modem is required for other purposes such
as alarm reporting, remote control, etc.
24.7.5
The External PSTN Modem connection shall be capable of sharing a PSTN line
with general purpose telephones at the site. To this end, an “Answer Defer
Time” option must be available which will cause the External Modem to wait
the specified period of time before answering the ringing line. This will give
personnel at the site the opportunity to answer the telephone in the normal
manner. After-hours or when personnel do not answer the telephone, the
Control Module will seize the line after the specified “Answer Defer Time” and
the PSTN connection to the Host computer may be established.
24.8
Processing
The Control Module shall maintain a sufficient database and provide control
processing such that all system functions will operate normally without
requiring connection to a host PC.
24.9
Programming
All System programming and database maintenance shall be possible via User
Terminals without requiring connection to a host PC.
24.10
Review (Event) Memory
The Control Module shall store a minimum of 300 Events in Review Memory.
Optional memory upgrades shall be available to provide up to 6500 Events in
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
48
Review memory. When the review memory is full, oldest events shall be
discarded to allow room for new events.
24.11
24.12
Inputs
(a)
The Control Module shall provide 16 End-Of-Line (EOL) supervised
inputs and a separate dedicated Cabinet Tamper input connection.
(b)
The Control Module shall be capable of logging and reporting the
following System Inputs (Firmware generated alarms):
1.
Cabinet Tamper
2.
Internal Siren (S1) Tamper
3.
External Siren (S2) Tamper
4.
Battery Test fail
5.
AC Fail
6.
Low Battery
7.
LAN fuse fail
8.
Detector fuse fail
9.
LAN Comms problem
10.
Program change
11.
Power on reset
12.
Line fault
13.
UART 1 fault
14.
UART 2 fault
15.
UART 3 fault
16.
UART 4 fault
17.
Zone Self test fail
18.
Time (test) report
19.
Manual trigger (test report)
20.
Comms Backup
21.
Comms Fail
22.
Phone
23.
Module substitution
24.
Request for Service
25.
Area pre-arm 1 test
26.
Area pre-arm 1 test fail
27.
Area pre-arm 2 test
28.
Area pre-arm 2 test fail
29.
Intelligent Reader Problem
30.
GSM Problem
31.
Expander Power Test
Outputs
The Control Module shall provide:
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
49
(a)
2 Auxiliary outputs each capable of switching up to 500mA. (e.g. To
switch strobes, sounders, etc.)
(b)
2 monitored Siren outputs each capable of driving 2 x 8-Ohm Siren
speakers wired in parallel.
(c)
Option to provide up to 8 additional Auxiliary outputs each capable of
switching up to 100mA;
OR Relay outputs capable of switching up to 5A.
24.13
24.14
Fault Diagnostics
The Control Module shall include on-board diagnostic LEDs to:
(a)
Assist with commissioning & troubleshooting.
(b)
Indicate LAN Receive and Transmit status.
Testing (Volts)
The Control Module shall include options allowing:
(a)
DC Supply (or Battery Charger) Voltage
(b)
DC Drain Current
(c)
AC Supply status and
(d)
Battery Voltage
to be viewed in real time with the display updated twice every second.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
50
25.
User Terminals
A range of User Terminals - with keypad, display and indicating devices - shall
be available, including:
26.
(a)
2x16 character LCD Terminal
(b)
Weatherproof and vandal resistant Terminal
(c)
LCD Touchscreen Terminal
2x16 character LCD Terminal
A minimum of one LCD User Terminal must be installed with the system.
Additional User Terminals shall be installed at suitable locations for performing
system operations, viewing system status, reviewing system activity, database
maintenance and Door control via PIN codes as required.
26.1
Design
The User Terminal shall be of an attractive and functional design with the
option to be surface mounted or flush mounted as required.
26.2
Display
User Terminals shall provide a 32-character backlit Liquid Crystal Display
(LCD) for displaying system status, alarm messages, user prompts, system
data, user help and system information in text form.
26.2.1
Up to 4 Indicator lamps (LEDs) shall also be provided and shall be fully
programmable for each individual Terminal to display Area and alarm status
and/or any other status condition required. When programmed to display
Area status the lamp shall be On when Area On, Off when Area Off and Flash
when Area in alarm.
26.3
Data Entry
User Terminals shall provide an ergonomic backlit keypad for User operations.
26.4
Ease of Use
All User Terminal operations shall be Menu driven with user friendly text
prompts for each function or action to be performed.
26.5
On-line Help
All User Terminals shall include a dedicated HELP key that provides the User
with context sensitive help and instructions in plain text via the LCD.
26.6
System Access
Programming options shall be able to define the Menu options and functions
allowed, Areas displayed and controlled, and Message types displayed at each
individual User Terminal.
26.7
System Maintenance
All System programming and database maintenance shall be possible via
specified User Terminals without requiring connection to a host PC.
26.8
Inputs
User Terminals shall include:
(a)
2 two-state (non EOL) Zone Inputs for monitoring of devices installed
near the Terminal or relevant to the functions performed at the
Terminal. (e.g. Egress device input, Door Reed input, etc.)
(b)
Separate dedicated on-board Cabinet Tamper switch.
(c)
Capability of logging and reporting the following System Inputs
(Firmware generated alarms):
1.
Cabinet Tamper
2.
Panic
3.
Door Forced
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
51
4.
Door Open Too Long
5.
Operator Duress
6.
Too many PIN tries
7.
LAN Comms fail
26.9
Outputs
User Terminals shall provide a minimum of 2 Auxiliary Outputs capable of
switching up to 100mA for control of devices installed near the Terminal or
relevant to the functions performed at the Terminal. (e.g. door locks,
sounders or indicator lamps, etc.)
26.10
Fault Diagnostics
User Terminals shall provide fault messages in plain text on the LCD display to
assist with commissioning & troubleshooting.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
52
27.
Weatherproof Terminals
27.1
Design
The Weatherproof Terminal shall be housed in an IP68 rated enclosure. It will
be water proof, dust proof and vandal resistant with no external moving parts.
27.2
Display
Up to 4 Indicator lamps (LEDs) shall be provided and shall be fully
programmable for each individual Terminal to display Area and alarm status
and/or any other status condition required. Default settings shall provide for
one lamp to indicate "logged on" status and one lamp to indicate the
associated Area On/Off (Armed/Disarmed) status while a User is logged on.
27.3
Inputs
Weatherproof Terminals shall include:
(a)
EOL supervised Door Reed input.
(b)
EOL supervised Tongue Sense input.
(c)
Request to Exit (REX) input.
(d)
Request to Enter (REN) input.
(e)
Separate dedicated Cabinet Tamper Input connection.
(f)
Capability of logging and reporting the following System Events
(Firmware generated alarms):
1.
Cabinet Tamper
2.
Keypad Tamper
3.
Keypad Cable Tamper
4.
Low supply voltage
5.
Door Forced
6.
Door Held
7.
Illegal Card/PIN
8.
LAN Comms Fail
27.4
Outputs
27.4.1
Relay
Weatherproof Terminals shall provide at least one relay (750mA @ 30VDC)
27.4.2
Auxiliaries
Weatherproof Terminals shall provide a minimum of 5 Auxiliary Outputs
capable of switching up to 100mA for control of devices installed near the
Terminal or relevant to the functions performed at the Terminal. (e.g.
sounders or indicator lamps, etc.)
27.5
Power Supply
Weatherproof Terminals shall be powered by 12V DC. The supply voltage may
be derived from the LAN.
27.5.1
If the Module is used to control a Door, then it must be powered by a separate
12V battery-backed power supply.
27.6
Readers
Weatherproof Terminal Modules shall also provide a single Reader connection
compatible with the Wiegand data format.
27.7
Functionality
Weatherproof Terminals shall provide the following Access Control
functionality options offered by the system:
(a)
Auto Area Off (Disarm)
(b)
Area On (Arm)
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
53
27.8
(c)
Request to Exit button
(d)
Request to Enter button
(e)
Extended unlock times
(f)
Anti-PassBack
(g)
Free Access (Time control)
(h)
Door Interlocking
Fault Diagnostics
Weatherproof Terminal Modules shall include on-board diagnostic LEDs to:
(a)
Assist with commissioning & troubleshooting.
(b)
Indicate LAN Receive and Transmit status.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
54
28.
Touchscreen Terminals
28.1
Design
The Touchscreen Terminal shall be of a modern design comprising a slimline
housing with a contemporary graphical interface.
28.2
Display
Touchscreen Terminals shall provide a full-colour graphical display measuring
240 by 320 pixels for displaying status, alarms, review, system events and
response to user commands.
28.3
Data Entry
The Touchscreen Terminal shall accept user input via the touchscreen. Buttons
and other screen elements will be large enough to press easily with an adult
thumb or finger.
28.4
Ease of Use
All Touchscreen Terminal operations shall be graphically driven with
descriptive text and icons making all functions easy to understand.
28.5
System Access
The Touchscreen Terminal shall provide access to the following functions:
(a)
Area control
(b)
On / off Auxiliary control and automation functions
(c)
Variable Level control of Automation Auxiliaries (C-Bus, Dynalite, HPM)
(d)
Isolate / de-isolate inputs
(e)
View and search review
(f)
View and acknowledge alarms
28.6
Touchscreen Configuration
Programming options shall allow a “layout” to be assigned to each individual
Touchscreen Terminal that defines the user screens for that terminal.
28.6.1
The number of “layouts” available shall be at least one more than the number
of Touchscreen Terminals available in the memory configuration used in the
system.
28.6.2
The system shall allow touchscreen layouts to be designed and managed
within the system management software. Whole layouts can be saved within
a Panel Template (.xml file), and copied and pasted to other panels.
28.6.3
The terminal can be configured to bypass user PIN codes for automation
functions only.
28.6.4
PIN codes will always be required to control areas.
28.7
Fault Diagnostics
User Terminals shall provide fault messages in plain text on the LCD display to
assist with commissioning & troubleshooting.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
55
29.
Input / Output Expansion
A range of Zone Expansion Modules shall be available that can be installed
remotely on the system LAN in suitable locations for decentralised connection
of Inputs, Sirens and Auxiliary Outputs.
29.1
Inputs
Each Zone Expansion Module shall provide 8, 16 or 32 EOL supervised Inputs
as required.
29.1.1
Utilising Zone Expansion Modules the system shall be capable of monitoring up
to 2048 additional EOL supervised Inputs.
29.2
Auxiliary Outputs
Every Zone Expansion Module shall provide as standard a minimum of 8 onboard Auxiliary Outputs capable of switching up to 150mA.
29.3
Fault Diagnostics
Expansion Modules shall include on-board diagnostic LEDs to assist with
commissioning & troubleshooting and to indicate LAN Receive and Transmit
status.
29.4
Off-line Operation
In the event of LAN communications failure with the Control Module, and as
long as power to the Expander Module is maintained, an Expander Module
shall store a record of any Zone Inputs and System Inputs that detect an
Alarm or Tamper condition.
29.4.1
When communications is re-established, the Expander Module shall send one
Alarm or Tamper message and one Restoral message (if restoral occurred) per
Input to the Control Module regardless of the number of Alarm or Tamper
events that have occurred on the Input. The time and date stamp on the
events shall be the time that the Control Module receives the message when
communications is restored.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
56
30.
8 Input Zone Expansion Modules
30.1
Power Supply
8 Input Zone Expansion Modules shall be powered by 12V DC from the LAN or
a separate 12V battery-backed power supply.
30.2
Relay Outputs
8 Input Zone Expansion Modules shall provide an option for 8 Relay Outputs
capable of switching up to 5A.
30.3
System Alarms
8 Input Zone Expansion Modules shall be capable of logging and reporting
“Low supply voltage” and “LAN Comms problem” System Inputs (Firmware
generated alarms).
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
57
31.
16 or 32 Input Zone Expansion Modules
31.1
Power Supply
16 Input Zone Expansion Modules shall be powered by16V AC from an
approved Transformer or Plug pack supplied with the Module. The module
shall include an on-board 13.8V DC power supply, battery charger and
connection for a 12V Sealed Lead Acid backup battery of 6.5 AH capacity.
31.2
32 Input Zone Expansion Modules
The 32 Input Zone Expansion Module shall consist of a standard 16 Input Zone
Expansion Module with a plug-on 16 Input Expander board fitted. This is to
ensure product consistency and ease of future expansion.
31.3
Additional Inputs
16 or 32 Zone Expansion Modules shall also include:
31.4
(a)
Separate dedicated Cabinet Tamper Input connection.
(b)
Capability of logging and reporting the following System Inputs
(Firmware generated alarms):
1.
Cabinet tamper
2.
Internal siren tamper
3.
External siren tamper
4.
Battery test fail
5.
AC fail
6.
Low battery
7.
LAN fuse fail
8.
Detector fuse fail
9.
LAN comms problem
10.
LAN Comms problem
Additional Outputs
16 or 32 Input Zone Expansion Modules shall also include:
(a)
2 Auxiliary Outputs each capable of switching up to 500mA. (e.g. for
control of strobes, sounders, etc.)
(b)
2 monitored Siren Outputs each capable of driving 2 x 8-Ohm Siren
Speakers wired in parallel.
(c)
Option to provide up to 24 additional Auxiliary Outputs each capable of
switching up to 100mA
OR 8, 16 or 24 Relay Outputs capable of switching up to 5A.
31.5
Selectable End-of-line Resistors
16 or 32 Zone Expansion Modules shall support selectable End-Of-Line (EOL)
resistor values. The value will be selected via a DIP-switch, and will affect all
Zone Inputs on the Module and the Zone Expansion Board (if fitted).
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
58
31.5.1
The supported values shall be:
Series EOL
(“sealed” value)
EOL across NC
alarm contact
Resultant “alarm”
value
2k2
6k8
9k0
1k0
1k0
2k0
2k2
2k2
4k4
2k2
4k7
6k9
4k7
4k7
9k4
10k
10k
20k
10k
10k
20k (or 5k for no
alarm contact wiring
scheme)
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
59
32.
Wireless Detection
32.1
SpreadNet®
The system shall be capable of interfacing to a C&K System’s SpreadNet®
Wireless Receiver via a single four wire, 9600 baud, RS232 serial connection
to a Control Module UART Port.
(a)
Monitoring and Logging
The SpreadNet® serial interface shall enable the system to individually
monitor and log Alarm, Tamper, Low Battery and Poll Timeout
conditions on up to 208 SpreadNet® Wireless Detection devices
(SpreadNet® Zone Inputs).
(b)
Reporting
The system shall be capable of reporting:
1.
Individual Alarm and Tamper conditions on SpreadNet® Zone
Inputs.
2.
Low Battery and Poll Timeout for groups of no more than 16
SpreadNet® Zone Inputs.
[SpreadNet® is a secure spread spectrum wireless system that supports
Wireless devices such as movement detectors, door reeds, smoke detectors,
and push buttons, etc.
Note: Only relevant in countries where SpreadNet® has the appropriate
communications authority approvals. E.g. United States, Canada, Australia,
Russia and South America. Check with local distributor of C&K Systems
products for other countries.]
32.2
Inovonics
The system shall be capable of interfacing to a Inovonics FA400 Serial
Receiver or MF 4232 Receiver via a UART Port and IR400 Inovonics Interface
board. The wireless transmitters can either be registered or programmed into
the system.
(a)
Monitoring and Logging
The Inovonics wireless interface shall enable the system to individually
monitor and log Alarm, Tamper, Low Battery and Poll timeout conditions
on up to 208 Inovonics® Wireless Detection devices.
(b)
Reporting
The system shall be capable of reporting:
1.
Individual Alarm and Tamper conditions on Inovonics Zone
Inputs.
2.
Low Battery and Poll Timeout for groups of no more than 16
Inovonics Zone Inputs.
[Note: For appropriate local communication authority approvals, please check
with Inovonics or their local distributors]
32.3
Visonic
The system shall provide a LAN-based RF Expander Module to interface with
Visonic PowerCode™ RF detection devices (e.g. movement detectors, reed
switches, panic buttons etc.) and CodeSecure™ 4-button RF portable
transmitters (fobs). The RF Expander Module shall come with a separate
Tamper Input and on-board diagnostic LEDs.
(a)
Monitoring and Logging
Each Control Module shall be capable of connecting up to 16 RF
Expander Modules via its System LAN with each RF Expander Module
being capable of monitoring up to 32 registered RF detection devices for
Alarm, Tamper, Low Battery and Poll Timeout conditions.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
60
(b)
Remote Control
Each Control Module shall be capable of registering up to 100 RF mobile
transmitters (fobs) to 100 Users. A choice of single button or 4-button
transmitters shall be available. The 4 buttons on a transmitter shall be
fully programmable with functions to Arm an Area, Disarm an Area,
Turn an Auxiliary On, Turn an Auxiliary Off or Generate an Alarm on a
nominated Zone Input.
(c)
Reporting
The system shall be capable of reporting:
1.
Individual Alarm and Tamper conditions on Visonic RF Zone
Inputs.
2.
Cabinet Tamper, Low Volt (LAN), RF Transmitter Low Battery,
RF Transmitter Poll Fail, RF Transmitter Jam and LAN Comms
Problem for each RF Expander Module.
[Note: For appropriate local communication authority approvals, please check
with Visonic or their local distributors]
32.4
32.5
RF Interface
The system shall provide a LAN-based RF Wireless Transceiver module to
interface with Paradox Magellan™ RF detection devices. These devices
include, but are not limited to, movement detectors (PIR’s), reed switches,
smoke detectors, and RF portable transmitters (fobs). The RF Transceiver
Module shall come with a separate Tamper Input and on-board diagnostic
LEDs.
(a)
Monitoring and Logging
Each Control Module shall be capable of connecting up to 16 RF Wireless
Transceiver Modules via its RS-485 LAN, with each RF Transceiver being
capable of monitoring up to 32 registered RF detection devices for
Alarm, Tamper, Low Battery and Poll Timeout conditions.
(b)
Remote Control
Each Control Module shall be capable of registering up to 100 RF mobile
transmitters (fobs) to 100 Users. A range of Paradox RF fobs are
available, including bi-directional fobs which give audible and visual
feedback of area status or input commands. The buttons on a
transmitter shall be fully programmable with functions to Arm an Area,
Disarm an Area, Turn an Auxiliary On, Turn an Auxiliary Off, Generate
an Alarm on a nominated Zone Input, Qualify a Zone Input, Qualify an
Auxiliary, or Toggle an Auxiliary.
(c)
Reporting
The system shall be capable of reporting:
1.
Individual Alarm and Tamper conditions on Paradox RF Zone
Inputs.
2.
Cabinet Tamper, Low Volt (LAN), RF Transmitter Low Battery,
RF Transmitter Poll Fail, RF Transmitter Jam and LAN Comms
Problem for each RF Transceiver.
Other Wireless Detection Systems
The system shall be capable of monitoring Dry Relay Contact outputs or Open
Collector outputs provided from a Wireless Detection system such that the two
wire connection between the Relay Output and the Zone Input can be
monitored for Seal, Alarm and Cable Tamper states.
(a)
Monitoring and Logging
The system shall be capable of individually monitoring and logging each
Relay Output provided by the Wireless Detection system.
(b)
Reporting
The system shall be capable of individually reporting each Relay Output
provided by the Wireless Detection system.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
61
33.
Door Controllers
A range of Door Access Modules shall be available that can be installed
remotely on the system LAN in suitable locations for decentralised connection
of Readers, Electric Locks, Door monitoring devices, Card and/or Door status
indication, general purpose Inputs and Auxiliary Outputs.
33.1
Number of Doors
Utilising Door Access Modules with the appropriate Control Module Memory
option and configuration, the system shall be capable of controlling and
monitoring up to 240 Doors.
33.2
Access Readers
The Readers required for Door access control shall be .…. and shall provide
.….data output format.
[Proximity or contact-less Smart Card readers] The read range shall be a
minimum of ….. cm as specified by the Reader manufacturer.
Reader Type
Data format
Inner Range Reader.
IR-Secure-40 Format.
Magnetic Swipe Readers.
OR
Magnetic Stripe Insert Readers.
Clock and Data.
MR Access Model 6AT1B Magnetic Swipe plus PIN
code reader
Clock and Data with keypad data.
HID Proximity Readers.
Indala Proximity Readers.
Motorola Indala Proximity Readers.
HID 5355 Proximity Reader with keypad.
Motorola ARK-501 Proximity Reader with keypad.
Keri P-600 Proximity Reader with keypad.
Wiegand.
Wiegand with buffered keypad data.
Wiegand Swipe Card Readers.
Wiegand.
Wiegand Key Insert Readers.
Wiegand.
Contact-less Smart Card Readers.
Wiegand.
Biometric Readers. e.g. Hand geometry, Fingerprint,
etc.
Wiegand.
Wiegand Keypads. e.g. Vandal-resistant keypads,
Weatherproof keypads, Scrambling keypads, etc.
Wiegand.
Other types.
Wiegand.
33.3
Reader Data formats
Door Controllers shall be compatible with the following Reader data
communication formats:
(a)
Clock & Data (e.g. Magnetic Stripe Readers)
(b)
Wiegand data (e.g. Proximity, Wiegand and Biometric Readers) formats.
33.4
Reader Power Requirements
Door Controllers shall support 5V and 12 Volt Reader supply voltages.
33.5
Card Formats
The system shall support the following Magnetic Stripe and Wiegand Card
formats:
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
62
(a)
Magnetic Swipe1
(b)
Magnetic Swipe Last
(c)
Magnetic stripe Insertion
(d)
Wiegand 26 Bit2
(e)
Wiegand 27 Bit
(f)
Wiegand 30 Bit
(g)
Wiegand 32 Bit
(h)
Wiegand 34 Bit
(i)
Wiegand 35 Bit
(j)
Wiegand 36 Bit
(k)
Wiegand 37 Bit
(l)
Wiegand 40 Bit
(m)
IR Secure 40 Bit
(n)
Swipe Raw (2-door controllers only)
(o)
N Bit Wiegand
(p)
N Bit Wiegand fast
(q)
Prox. + PIN Wiegand
33.5.1
The system shall provide an option allowing the installer to define the Card
data format of Cards encoded with site code and card number. This option
shall allow the installer to specify the position and length of the site code and
card number data.
33.5.2
This option shall support card data being sequential from most significant to
least significant bit with maximum total data length of 40 bits (Wiegand) or 15
characters (Mag swipe).
33.5.3
This option shall allow processing of Site code data of up to 19 bits (Wiegand)
or 10 characters (Mag swipe); and card number data of up to 16 bits
(Wiegand) or 5 characters (Mag swipe).
33.6
Door Control Hardware Selection - CONCEPT ACCESS 4000 Systems
NOTE: The Type of Door Access Module used is determined by the level of
redundancy required and the number of Doors to be controlled in the vicinity
of the Module.
33.6.1
IMPORTANT NOTES:
(a)
Control equipment requirements stated below assume the use of
standard 12-Volt electric lock strikes requiring up to 250mA holding
current.
(b)
Additional Power Supplies may be required for locks demanding heavier
current requirements such as Magnetic locks, or where longer battery
backup times are required.
(c)
The Intelligent 4 Door Access Module on-board Power Supply can
provide up to 2 Amps total Current for Locks, Readers, Detectors,
Auxiliaries and local LAN power. If the total current requirement
exceeds this, one or more separate 2 Amp Power Supplies should be
used to power the Locks.
1
Inner Range Magnetic Swipe Cards support Site Codes.
2
Industry standard Wiegand format supporting Site Codes.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
63
(d)
Additional Power Supplies may be required where the physical locations
of multiple Single Door or 2 Door Access Modules makes it impractical to
use a common power supply.
(e)
Backup Batteries are not listed. Note that a 6.5AH Sealed Lead Acid
(SLA) battery is required for each 2A Power Supply and a 6.5AH or
15AH SLA battery is required for each Intelligent 4 Door Access Module.
Desired Configuration
Single Door / 2 Door Access
Module (“backup cards”
function when offline)
Intelligent 4 Door Access
Module (full access control
functionality maintained when
offline)
1 Door. IN Reader only.
1 x Single Door Access Module.
1 x Intell. 4 Door Access Module.
1 x 2A Power Supply.
1 Door. IN & OUT Readers.
1 x 2 Door Access Module.
1 x Intell. 4 Door Access Module.
1 x 2A Power Supply.
2 Doors. IN Reader only.
1 x 2 Door Access Module.
1 x Intell. 4 Door Access Module.
1 x 2A Power Supply.
OR
2 x Single Door Access Module.
1 x 2A Power Supply.
2 Doors. IN & OUT
Readers.
2 x 2 Door Access Modules.
3 Doors. IN Reader only.
3 x Single Door Access
Modules.
1 x Intell. 4 Door Access Module.
1 x 2A Power Supply.
1 x Intell. 4 Door Access Module.
2 x 2A Power Supplies.
33.7
Single Door / 2 Door Controllers
33.8
Power Supply
Single Door / 2 Door Controllers shall be powered by 12V DC from a separate
12V battery-backed power supply. Door Control Modules shall not be powered
from the LAN.
33.9
Readers
Single Door / 2 Door Controllers shall provide a single Entry Reader connection
for each Door.
33.9.1
2 Door Access Modules shall be able to be configured for Single Door operation
providing connection for an IN Reader and OUT Reader on a single Door.
33.10
Inputs
Single Door / 2 Door Controllers shall include:
(a)
Separate EOL supervised Door Reed for each Door.
(b)
Separate EOL supervised Tongue Sense option for each Door.
(c)
Separate Request to Exit (REX) for each Door.
(d)
Request to Enter (REN) (2 Door Access Module only)
(e)
Area Arm.
(f)
Separate dedicated Cabinet Tamper Input connection.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
64
(g)
33.11
33.12
33.13
Capability of logging and reporting the following System Inputs
(Firmware generated alarms):
1.
Cabinet Tamper
2.
Low supply voltage
3.
1st Door Forced
4.
1st Door Held
5.
2nd Door Forced3
6.
2nd Door Held3
7.
Illegal Card (either Door)
8.
LAN Comms Fail
Outputs
Single Door / 2 Door Controllers shall include the following for each Door:
(a)
Lock Relay capable of switching 750mA for each Door.
(b)
Valid Card / Invalid Card / Door Open Too Long (DOTL) warning for each
door. (May be combined on a single output for each door)
Functionality
Whilst On-line, Single Door / 2 Door Controllers shall provide the full range of
Access Control functionality options offered by the system including:
(a)
Dual User access
(b)
Card + PIN access
(c)
Anti-PassBack
(d)
Door Interlocking
(e)
Auto Area Off
(f)
Area On (Arm)
(g)
Free Access (Time control)
(h)
Extended unlock times
Off-line Operation
When Off-line, (e.g. Temporary LAN communications failure or Control Module
failure) Single Door / 2 Door Controllers shall provide basic 24 Hour Door
Access Control for:
(a)
The last 110 cards used at each Reader Head (2-Door Controllers only)
(b)
Up to 31 cards nominated by the system administrator
(c)
Up to 127 cards nominated by the system administrator
(Select the required option/s.)
33.14
3
Fault Diagnostics
Single Door / 2 Door Controllers shall include on-board diagnostic LEDs to:
(a)
Assist with commissioning & troubleshooting.
(b)
Indicate LAN Receive and Transmit status.
Not relevant on Single Door Access Modules.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
65
34.
Intelligent Four Door Controllers
34.1
Power Supply
Intelligent Door Controllers shall be powered from 16V AC via an approved AC
Mains Transformer supplied in the Module enclosure. The Transformer shall
have a 1.5m mains cord fitted for connection to a 3 pin GPO. The module
shall include an on-board 13.8V DC power supply, battery charger and
connection for a 12V Sealed Lead Acid backup battery of between 6.5 AH to
17 AH capacity.
34.2
Door Capacity
Intelligent Door Controllers shall provide full control and monitoring of up to 4
Doors.
34.3
Reader connections
Intelligent Door Controllers shall provide 4 on-board Reader connections that
can be individually assigned as the IN Reader or OUT Reader for any of the 4
Doors controlled by the Module.
i.e. An Intelligent Door Controller shall be capable of controlling 2 Doors with
IN and OUT Readers without requiring any additional Reader interface
hardware to be fitted.
34.3.1
Up to 4 additional Reader connections shall be available via a plug-on 4
Reader Expansion board. The additional Reader connections shall also be able
to be individually assigned as the IN Reader or OUT Reader for any of the 4
Doors controlled by the Module.
34.4
LAN Connection
The Intelligent Door Controllers shall provide a minimum of 5kV Isolation
between the Module and the system LAN without requiring any additional
hardware to be installed.
34.5
User Terminals
User Terminals required for “Card AND PIN” or “Card OR PIN” access
requirements shall be connected to a separate local LAN connection on the
Intelligent Door Controller. Whilst the Module is On-line the local LAN shall be
transparently interfaced to the system LAN allowing the option of full system
functionality on these Terminals as required.
34.6
Inputs
Intelligent Door Controllers shall include the following dedicated Inputs for
each Door:
34.7
4
(a)
EOL supervised Door Reed for each Door.
(b)
EOL supervised Tongue Sense option for each Door.
(c)
Request to Exit (REX) for each Door.
(d)
Request to Enter (REN) for each Door.
(e)
Area Arm Button for each Door.
Intelligent Door Controllers shall also include the following Inputs:
(a)
Minimum of 8 General purpose EOL supervised Inputs.
(b)
Separate dedicated Cabinet Tamper Input connection.
(c)
Capability of logging and reporting the following System Inputs
(Firmware generated alarms):
1.
1st Door Lock Tamper4
2.
2nd Door Lock Tamper4
3.
3rd Door Lock Tamper4
Available when lock wired in the normal "power to lock" configuration.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
66
4.
4th Door Lock Tamper4
5.
1st Door Forced
6.
2nd Door Forced
7.
3rd Door Forced
8.
4th Door Forced
9.
1st Door DOTL
10.
2nd Door DOTL
11.
3rd Door DOTL
12.
4th Door DOTL
13.
1st Door Illegal Card
14.
2nd Door Illegal Card
15.
3rd Door Illegal Card
16.
4th Door Illegal Card
17.
Cabinet Tamper
18.
General Lock fault
19.
Battery Test fail
20.
AC Fail
21.
Low Battery
22.
LAN fuse fail
23.
Detector fuse fail
24.
LAN Comms problem
34.8
Outputs
Intelligent Door Controllers shall include the following dedicated Outputs for
each Door:
34.8.1
These Outputs shall be capable of controlling Reader LEDs and/or Beepers or
other devices as required.
34.8.2
34.9
(a)
Lock Relay capable of switching 5A.
(b)
Valid indication
(c)
Invalid indication.
(d)
Door Open Too Long (DOTL) warning.
Intelligent Door Controllers shall also include the following Outputs:
(a)
Minimum of 8 General purpose Auxiliary Outputs capable of switching up
to 150mA.
(b)
AN option shall be available to utilise 4 of the general purpose Auxiliary
Outputs to provide a dedicated “disabled access” output for each door
for the purpose of activating door opening mechanisms.
Functionality
Whilst On-line, Intelligent Door Controllers shall provide the full range of
Access Control functionality options offered by the system including:
(a)
Dual User access
(b)
Card + PIN access
(c)
Anti-PassBack
(d)
Door Interlocking
(e)
Auto Area Off
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
67
34.10
(f)
Area On (Arm)
(g)
Free Access (Time control)
(h)
Extended unlock times
(i)
Defer Arming via readers
Off-line Operation
(e.g. Temporary LAN communications failure or Control Module failure)
The Intelligent Door Controller shall maintain a local up-to-date database of all
relevant system data required to provide normal Door access control
functionality when Off-line including:
(a)
User’s normal Door access permissions and restrictions.
(b)
User TimeZone restrictions.
(c)
Door Free Access times.
(d)
Anti-PassBack. (Limited to Doors on the same Intelligent Door
Controller)
(e)
Door Interlocking. (Limited to Doors on the same Intelligent Door
Controller)
34.11
Disabled User Auxiliaries
The Intelligent Door Controller shall allow corresponding on-board general
purpose auxiliaries to follow the Lock Auxiliaries 1-4 respectively, when a
“Disabled” User accesses the Door. This feature will provide an output that can
be used to trigger electric specific Door opening mechanisms on a valid Door
Access event, but only when accessed by a User that is flagged as being a
“Disabled” User in the system.
34.11.1
The Intelligent Door Controller shall make Disabled User Auxiliaries available
in both On-line and Off-line modes.
34.12
Database Maintenance
Any system programming changes relevant to Intelligent Door Controllers
shall be automatically downloaded to the Controllers without requiring any
special User operation.
34.12.1
In the event that an Intelligent Door Controller is receiving a full download of
relevant programming from the Control Module, other up-to-date Intelligent
Door Controllers shall not be affected by the process and will continue
functioning as normal.
34.13
Event Log
Each Intelligent Door Controller shall maintain a local Event log of a size equal
to that of the Control Module. (300 Events, 2000 Events or 6500 Events
depending on the Control Module Memory size)
34.13.1
When the review memory is full, oldest events shall be discarded to allow
room for new events.
34.13.2
An optional shall be available, programmable per door, which prevents “user
access granted” events being logged to review unless the door is actually
opened after the card presentation.
34.13.3
When this option is enabled and a door is not opened following a valid card
presentation, a “not opened” event shall be logged.
34.14
Time & Date Stamp
All Events shall have a time and date stamp that includes the Month, Date,
and time accurate to 1/10ths of a second.
34.15
On-line / Off-line Event Logging
When On-line, Events shall be logged locally and uploaded to the Control
Module as they occur in real-time.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
68
34.15.1
When Off-line, Access Control Events shall continue to be logged locally by
each Intelligent Door Controller and shall be endorsed with a special character
after the date to identify the Event as occurring whilst the Door Controller was
off-line. When LAN communications is re-established, the Intelligent Door
Controller shall transfer the Events that have occurred whilst off-line, to the
Control Module at a rate that will not affect the normal operation of the
system.
34.15.2
Any general purpose Zone Input and System Input alarms shall also be
stored, however only one alarm message and one restore message (if a
restore occurred) per Input shall be sent to the Control Module when
communications is re-established.
34.16
Fault Diagnostics
Intelligent Door Controllers shall include on-board diagnostic LEDs to:
(a)
Assist with commissioning & troubleshooting.
(b)
Indicate LAN Receive and Transmit status.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
69
35.
Lift Controllers - Access Reader Interface
35.1
Reader Interfaces
Reader Interface Modules shall be available that can be installed remotely on
the system LAN in the Lift Cars for connection of Readers, Card and/or status
indication, general purpose Inputs and Auxiliary Outputs.
[Single Door / 2 Door Access Modules recommended]
35.2
Reader Interface Power Supply
Reader Interface Modules installed in Lift Cars shall be powered by 12V DC
from a separate 12V battery-backed power supply. Reader Interface Modules
shall not be powered from the LAN.
35.3
LAN Isolation
A LAN Isolator/Repeater device shall be installed at each Access controlled Lift
at a suitable point before the LAN cabling enters the Elevator shaft. These
devices are provided to isolate the section of LAN cable connecting to the
Access Module in the Lift Car. The devices shall provide a minimum of 2.5kV
Isolation between each section of the LAN connected to the device.
35.4
Number of Lifts.
Utilising standard system Modules the system shall be capable of controlling
and monitoring up to 32 Lift Cars.
35.5
Access Readers
The Readers required for Lift Access Control shall be..…and shall provide …..
data output format.
35.5.1
[Proximity or contact-less Smart Card Readers] The read range shall be a
minimum of ….. cm as specified by the Reader manufacturer.
Reader Type
Data format
Inner Range Reader.
IR-Secure-40 Format.
Magnetic Swipe Readers.
OR
Magnetic Stripe Insert Readers.
OR
Clock and Data.
Weatherproof Magnetic Swipe Readers.
HID Proximity Readers.
Wiegand.
HID 5355 Proximity Reader with keypad.
Wiegand with buffered keypad data.
Indala Proximity Readers.
Motorola Indala Proximity Readers.
Wiegand.
Motorola ARK-501 Proximity Reader with keypad.
Wiegand with buffered keypad data.
Keri P-600 Proximity Reader with keypad.
Wiegand with buffered keypad data.
Wiegand Swipe Card Readers.
Wiegand.
Wiegand Key Insert Readers.
Wiegand.
Contact-less Smart Card Readers.
Wiegand.
Biometric Readers.
e.g. Hand geometry, Fingerprint, etc.
Other types.
35.5.2
Wiegand.
Wiegand.
Reader Interfaces shall be compatible with the following Reader data
communication formats:
(a)
Clock & Data (e.g. Magnetic Stripe Readers)
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
70
(b)
Wiegand data (e.g. Proximity, Wiegand and Biometric Readers) formats.
35.6
Reader Power Requirements
Reader Interfaces shall support 5V and 12 Volt Reader supply voltages.
35.7
Card Formats
The Lift access control system shall support the following Magnetic stripe and
Wiegand Card formats:
(a)
Magnetic Swipe
(b)
Magnetic Swipe Last
(c)
Magnetic stripe Insertion
(d)
Wiegand 26 Bit
(e)
Wiegand 27 Bit
(f)
Wiegand 30 Bit
(g)
Wiegand 32 Bit
(h)
Wiegand 34 Bit
(i)
Wiegand 35 Bit
(j)
Wiegand 36 Bit
(k)
Wiegand 37 Bit
(l)
Wiegand 40 Bit
(m)
IR Secure 40 Bit
(n)
Swipe Raw
(o)
N Bit Wiegand
(p)
N Bit Wiegand fast
(q)
Prox. + PIN Wiegand
(r)
IR-Secure-40
35.7.1
The system shall provide an option allowing the installer to define the Card
data format of Cards encoded with site code and card number. This option
shall allow the installer to specify the position and length of the site code and
Card number data.
35.7.2
This option shall support Card data being sequential from most significant to
least significant bit with maximum total data length of 40 bits (Wiegand) or 15
characters (Mag swipe).
35.7.3
This option shall allow processing of Site code data of up to 19 bits (Wiegand)
or 10 characters (Mag swipe); and Card number data of up to 16 bits
(Wiegand) or 5 characters (Mag swipe).
35.8
Inputs
Reader interfaces shall include:
(a)
Separate dedicated Cabinet Tamper Input connection.
(b)
Capability of logging and reporting the following System Inputs
(Firmware generated alarms):
1.
Cabinet Tamper
2.
Low supply voltage
3.
Illegal Card
4.
LAN Comms Fail
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
71
35.9
Outputs
Reader interfaces shall include the following for each Lift:
(a)
35.10
35.11
Valid Card / Invalid Card indication. (May be combined on a single
output for each lift)
Functionality
Reader interfaces shall provide the full range of Access Control functionality
options offered by the system including:
(a)
Dual User access
(b)
Card + PIN access
(c)
Free Access (Time control)
(d)
Extended unlock times
Fault Diagnostics
Reader interfaces shall include on-board diagnostic LEDs to:
(a)
Assist with commissioning & troubleshooting.
(b)
Indicate LAN Receive and Transmit status.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
72
36.
Lift Controllers - Lift Control Equipment Interface
36.1
Number of Floors
Utilising standard system Expansion Modules the system shall be capable of
controlling and monitoring up to 64 Floors per Lift Car.
36.1.1
Low-level Interface - No Button Monitoring
36.1.2
(a)
Expansion Modules for Lift Control Interface shall be installed remotely
on the system LAN in or near the Lift Motor Room/s.
(b)
The Expansion Modules shall provide for “Normally Open” and “Normally
Closed” Dry Relay Contacts to Enable/Disable Floor selection buttons for
each Lift Car to be controlled. These Relay Contacts shall be electrically
isolated from the Access Control system.
(c)
For ease of maintenance, the Relays shall be provided on separate Relay
Boards that connect to the Expansion Module. Each Relay Board shall
provide no more than 8 Relays.
Low-level Interface - With Button Monitoring
(a)
Expansion Modules for Lift Control Interface shall be installed remotely
on the system LAN in or near the Lift Motor Room/s.
(b)
The Expansion Modules shall provide for the following Inputs and
Outputs:
1.
Opto-isolated Inputs capable of monitoring Lift button circuit
voltages of 16 to 48V DC. (Full Wave rectified and Non
regulated) Input circuits shall provide a minimum of 850V
Isolation from the button circuit.
2.
“Normally Open” and “Normally Closed” Dry Relay Contacts
to select the specific Floor requested by the User. Relay
contacts shall be capable of switching 30W or 62.5VA within
the following voltage and current limits:

500milliAmps at 48V DC or 48V AC RMS. [If Concept
Access 4000 994020 Lift I/faces used.]
OR

3.
36.1.3
200milliAmps at 120V DC or 150V AC RMS. [If Concept
Access 4000 994020HV Lift I/faces used.]
For ease of maintenance, the Inputs and Relays shall be
provided on separate Interface Boards that connect to the
Expansion Module. Each Relay Board shall provide no more
than 8 Inputs/Relays and the Relays shall be mounted in
sockets.
High-level Interface
(a)
The system shall provide a serial data connection for Interface to the
Lift Control Equipment.
(b)
Communication shall be via RS232 serial data at 300 / 600 / 1200 /
2400 / 4800 / 9600 baud.
(c)
The serial interface shall provide the ability to enable the relevant floors
for selection after a valid card read.
OR
(d)
The serial interface shall provide the ability to monitor the Floor button
selections after a card is read and, after processing, return a command
to select a specific floor.
[Dependant on Lift protocol used]
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
73
36.1.4
IMPORTANT NOTES:
(a)
Contact Inner Range for details of High Level Lift protocols supported,
functions supported and baud rate required.
(b)
Ensure that all relevant local and/or national regulations allow use of
High-Level Lift Interfaces for access control.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
74
37.
Power Supplies - Stand-alone
37.1
AC Input
Power supplies shall be powered from an AC mains supply of 240V AC +/-10%
and be fitted with an approved Power Transformer.
37.2
Output Voltage
Any Power Supplies used within the system shall maintain an output voltage
under static load:
37.3
(a)
Within 2% of the rated output voltage at 90% of the rated current
output;
(b)
And within 5% of the rated output voltage at 100% of the rated current
output.
Output Protection
Fuse protection shall be provided for the following Outputs
(a)
Battery Input.
(b)
Detector Output.
37.4
Spurious Emissions
Power Supplies shall be of a design that does not interfere with the operation
of other system devices such as Proximity Readers and Wireless detectors and
shall comply with appropriate regulations.
37.5
Backup Battery
Power Supplies shall include a battery charger and connection for a Sealed
Lead Acid Battery of at least 6.5 AH capacity.
37.6
Fault Monitoring
Power Supplies shall provide separate AC Mains Fail and Low Battery outputs
that can be monitored by inputs on a suitable system Module. AC Mains fail,
Output present and Battery reversed / Battery fuse fail shall be indicated
locally on the Power supply PCB by indicator lamps (LEDs).
37.7
Battery Testing
Power Supplies shall have a control input to allow the regulator to be switched
off by a remote device for the purposes of automated battery testing if
required.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
75
38.
Power Supplies -Intelligent (LAN Comms Capability)
38.1
Design
LAN Power Supply Modules shall be available to be utilized wherever batterybacked 12V power supplies are required. They shall be capable of reporting
status of Fault, Tamper, Input and Output conditions immediately via LAN
communications without additional wiring.
38.2
LAN Connection
LAN connection shall be provided allowing the module to be connected
anywhere along the System LAN.
38.3
AC Input
LAN Power Supply modules shall be powered from 16V AC +/-10% via an
approved 240V AC Mains Transformer supplied in the module enclosure.
38.4
Power Supply Outputs
The module shall include a 13.75V power supply output and battery charger
output.
38.4.1
Any Power Supplies used within the system shall maintain an output voltage
under static load:
38.4.2
(a)
Within 2% of the rated output voltage at 90% of the rated current
output;
(b)
And within 5% of the rated output voltage at 100% of the rated current
output.
A single module shall be capable to provide a total output current up to 4A
for:
(a)
Battery Charging
(b)
Combined current drawn by: Auxiliaries, Detectors and System LAN.
38.4.3
An option shall be available to connect up to 4 LAN Power Supply Modules
together in a Master/Slave configuration to provide additional Battery
Charging current and/or Detector current up to a total combined current
output of 16A.
38.5
Backup Battery
LAN Power Supplies shall include a battery charger and connection for a 12V,
Sealed Lead Acid Battery of at least 6.5 AH capacity.
38.6
Battery Testing
LAN Power Supplies shall have an option to be included in Automatic Battery
Testing procedures. These procedures shall provide a programmable start
time that allows the Battery Test sequence to commence daily / weekly /
monthly / annually [As required], and a test time specified separately for each
Module to be tested. (Allowing for variations in the load current of each
Module.)
38.7
Spurious Emissions
Power Supplies shall be of a design that does not interfere with the operation
of other system devices such as Proximity Readers and Wireless detectors and
shall comply with appropriate regulations.
38.8
Fault Diagnostic LEDs
The module shall include on-board diagnostic LEDs to:
38.9
(a)
Assist with testing, commissioning and trouble-shooting LAN
communications.
(b)
Indicate LAN activity.
(c)
Indicate presence of AC Input, 13.75V supply and 5V supply.
Inputs and Fault monitoring
The module shall include two on-board general purpose EOL supervised
Inputs.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
76
38.9.1
38.10
38.11
It shall also log and report the following System Inputs (Firmware generated
alarms):
(a)
Cabinet Tamper
(b)
AC Fail
(c)
Low Battery
(d)
Detector Fuse Fail
(e)
LAN Fuse Fail
(f)
Battery Fuse Fail
(g)
AUX 2 Fuse Fail
(h)
AUX 2 Tamper
(i)
Detector Over-current
(j)
Battery Over-current
(k)
Over Volts
(l)
Low Volts
(m)
Battery Fail
(n)
Slave Fail
(o)
Battery Test Fail
(p)
LAN Comms Problem
Auxiliary Outputs
The module shall include the following Outputs:
(a)
A general purpose Auxiliary Output capable of switching up to 200mA.
(b)
With the option to provide one additional Auxiliary output capable of
providing 13.75V DC to control Satellite Siren Unit or other external
controlled device.
(c)
When connecting to external devices, programming option shall allow an
output current value to be nominated. A tamper alarm shall be
generated when the output current falls below this nominated output
current level.
Output Protection
Fuse protection shall be provided for the following Outputs
(a)
Battery Input.
(b)
Detector Output.
(c)
LAN Power Output.
(d)
Satellite Siren / Auxiliary Output.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
77
39.
Analogue Input Monitoring
A Module shall be available that can be installed remotely on the system LAN
in suitable locations for monitoring of Analogue values.
39.1.1
The Analogue Module shall support a Serial Temperature Sensor option to
eliminate the need for voltage or current loop sensing when monitoring
temperatures.
39.2
Power Supply
Analogue Modules shall be powered by 12V DC from the LAN or a separate
12V battery backed up power supply.
39.3
Inputs
Each Analogue Module shall provide:
(a)
Up to 4 Inputs for Analogue sensor devices or serial temperature
sensors.
(b)
2 general purpose Zone Inputs.
39.3.1
Utilising Analogue Modules the system shall be capable of monitoring up to 32
Analogue sensor devices using standard programming options.
39.3.2
Utilising Analogue Modules the system shall be capable of monitoring up to
396 Analogue sensor devices using a customised system configuration.
39.3.3
Installation options for each individual Analogue Input shall provide for the
following Analogue Input signals:
(a)
Voltage sensing. 0V to 5V DC. Uni-polar referenced to 0V input
terminal. (Input is polarised)
(b)
Current loop sensing. 4mA to 20mA DC polarised. Input termination
resistor selectable.
(c)
Serial Temperature Sensor.
39.4
Analogue Input Processing - General
The Analogue to Digital Converter shall provide a minimum of 8-bit resolution.
39.4.1
Analogue Input processing shall allow an alarm or seal condition to be
generated when an Input exceeds or drops below one or more preprogrammed trigger values.
39.4.2
Programming options shall provide for these changes of state on Analogue
Inputs to be logged and activate Messages, Auxiliary Outputs, Alarms, Central
Station reports, etc. as required.
39.4.3
Programming options shall allow the actual value on any Analogue Input to be
viewed via a Menu option on the User Terminal and/or on a host PC connected
to the system. The name of the Input shall be displayed in plain text and the
value shown in meaningful scaled units.
39.5
Analogue Input Processing - Voltage or Current Loop Sensing
A programmable Trigger value shall be provided for each Analogue Input.
39.5.1
The Input shall generate a Seal state below the programmed Trigger value
and an Alarm state above the programmed Trigger value. A Tamper state
shall be generated if the Analogue value is outside the expected range. [Mode
0]
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
78
39.6
Analogue Input Processing - Serial Temperature Sensor
The system shall provide programming options to accommodate the following
processing Modes:
(a)
A programmable Trigger value shall be provided for each Serial Input.
The Input shall generate a Seal state below the programmed Trigger
value and an Alarm state above the programmed Trigger value. A
Tamper state to indicate a fault condition shall be generated if the value
is outside the expected temperature range of 0º to +30º Celsius.
[Mode 1]
(b)
The Output value of a Serial Temperature Sensor connected to Input 1
or 3 shall be mirrored on the next Input. (i.e. Input 2 or 4 respectively)
A programmable Trigger value shall be provided for each Input
effectively providing two independent Trigger points per Sensor. Each
Input shall generate a Seal state below the programmed Trigger value
and an Alarm state above the programmed Trigger value. A Tamper
state to indicate a fault condition shall be generated if the value is
outside the expected temperature range of 0º to +30º Celsius. [Mode
2]
(c)
The Output value of a Serial Temperature Sensor connected to Input 1
shall be mirrored on Inputs 2, 3 and 4. A programmable Trigger value
shall be provided for each Input effectively providing four independent
Trigger points per Sensor. Each Input shall generate a Seal state below
the programmed Trigger value and an Alarm state above the
programmed Trigger value. A Tamper state to indicate a fault condition
shall be generated if the value is outside the expected temperature
range of 0º to +30º Celsius. [Mode 3]
(d)
Two programmable Trigger values shall be provided for each Serial
Input. The trigger values shall define the “mean value of the desired
range” and the “dead band value”, thus providing a “minimum desired
value” and “maximum desired value” for each Serial Input. Each Input
shall generate a Seal state below the minimum desired value, a Tamper
state between the minimum and maximum desired values, and an
Alarm state above the maximum desired value. [Mode 4]
(e)
Two programmable Trigger values shall be provided for each Serial
Input operating as per Mode 4 but providing a temperature range of 55º to +70º Celsius. [Mode 5]
39.7
Auxiliary Outputs
Each Analogue Module shall provide as standard a minimum of 4 on-board
Auxiliary Outputs capable of switching up to 150mA.
39.8
Fault Diagnostics
Analogue Modules shall include on-board diagnostic LEDs to:
39.9
39.10
(a)
Assist with commissioning & troubleshooting.
(b)
Indicate LAN Receive and Transmit status.
System Alarms
Analogue Modules shall be capable of logging and reporting the following
System Inputs (Firmware generated alarms):
(a)
Cabinet Tamper
(b)
Low supply voltage
(c)
LAN Comms problem
Monitoring and Logging
The system shall individually monitor and log activity on each Analogue Input
and be capable of reporting changes of state above and/or below one or more
pre-programmed trigger values to a local and/or remote Central Monitoring
Station.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
79
40.
Dual-Format Proximity Reader
A dual-format proximity reader shall be available that can be connected to
Door Access Modules and read prox cards in a variety of formats.
40.1
Power Supply
Dual-format Proximity Card Readers can be powered by 12V DC from an
attached Inner Range Door Access Module (current consumption 85mA max).
40.2
Warm-up Time
The warm up time shall be less than 15 seconds from application of power.
40.3
Configuration
The reader shall be capable of supporting the following card formats:
40.3.2
(a)
Inner Range Secure40 format
(b)
125kHz FSK Proximity Card format from 26 bit to 40 bit
(c)
EM 125kHz ASK format
An advanced configuration kit shall be available that allows the Reader to be
configured for the following modes of operation:
(a)
Single-mode operation where any one of the three available formats
may be selected to enhance the processing speed and, if mounted on
metallic surfaces, the read range.
(b)
Dual-mode operation where any two of the three available formats may
be selected to allow for sites that utilize both formats.
40.4
Read Range
The dual-format proximity reader shall have a maximum read range of
150mm using proximity cards (where power supply ripple is less than 150
mV). If the reader is mounted on metal the effective range may be reduced.
40.5
User Identification
User identification devices, compatible with the Proximity Reader specified,
shall be available in the following types:
40.5.1
(a)
Clamshell Cards
(b)
ISO cards compatible with Photo ID printer
(c)
Key fobs
The data format of the User ID devices shall support the following features:
(a)
A “registered site” service that enables customers to register a unique
site code for an individual site or client.
(b)
No duplication of any card issued.
(c)
Encrypted data.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
80
41.
Fibre Modems
A fibre modem shall be available that provides two separate, optically isolated
ports to the LAN.
41.1
Single Mode vs. Multi-mode
The fibre modem shall be available in two types – single mode and multimode.
41.1.1
In single mode fibre modems, each port will have a transmit / receive pair
with SC connectors which will accommodate single-mode 9/125 μm optical
fibre cables.
41.1.2
In multi mode fibre modems, each port will have a transmit / receive pair with
SC connectors which will accommodate multi-mode 62.5/125 μm optical fibre
cables.
41.2
Power
Fibre Modems shall be powered by 12V DC from the LAN or a separate 12V
battery-backed power supply (maximum current draw 260mA).
41.3
Indicators
LED indicators show operational status (RUN) and the status of each receive
line (FAULT). Data flow shall be indicated with TX and RX LED indicators for
each of the three ports.
41.3.1
Outputs
Two switched outputs shall be provided, which can be wired directly into Zone
Inputs on a module to monitor the state of each receive port.
Fault
Fault LED
OUT 1
OUT 2
Data detected on both ports
OFF
Seal
Seal
Data not detected on port 1
Fast flash
Alarm
Seal
Data not detected on port 2
Slow flash
Seal
Alarm
ON
Alarm
Alarm
Data not detected on both ports
41.4
Topology
The Fibre Modem shall be usable in a “LOOP” mode or in a “STAR” mode to
create 2 separate electrically isolated LAN segments. The Fibre Modems can
also be “daisy chained” to cover larger sites.
41.4.1
Transmission Distance
The typical transmission distance between each fibre modem shall be 3000
metres.
41.4.2
Deployment Considerations
When designing the Fibre Modem network for a particular Concept 3000/4000
system, a number of factors will limit the number of Fibre Modems and/or the
length of fibre optic cabling that can be used. These are as follows:
41.4.3
(a)
The Fibre Modem signal processing delay.
(b)
The propagation delay and signal attenuation of the Optical Fibre cable
connected between Fibre modems.
(c)
The propagation delay and signal attenuation of the RS485 twisted pair
LAN cable connecting the Fibre modem to the Concept 3000/4000
Modules.
Single Mode
To simplify the single-mode fibre network design, the following rules shall be
adhered to:
(a)
Maximum length of Optical Fibre cable between two Fibre Modems must
not exceed 13000 metres (13km).
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
81
41.4.4
(b)
Maximum length of twisted pair LAN cable from a Fibre Modem LAN Port
to the furthest Module on that segment of LAN must not exceed 1500m
(1.5km).
(c)
No two Modules on the LAN shall be more than 15 “Delay Units” apart.
(d)
When used in a loop configuration, the Fibre optic loop may be no more
than 14 “Delay Units” in length.
The number of “Delay Units” is calculated as follows:
(a)
Add 1 Delay Unit for each Fibre Modem in the path.
(b)
Add 1 Delay Unit for each 1000 metres (1km) of Optical Fibre cable in
the path.
(c)
Add 1 Delay Unit for each 1350 metres (1.35km) of twisted pair LAN
cable in the path.
41.4.5
Multi-Mode
41.4.6
To simplify the multi-mode fibre network design, use the following rules.
41.4.7
(a)
Maximum length of Optical Fibre cable between two Fibre Modems must
not exceed 3000 metres (3km).
(b)
Maximum length of twisted pair LAN cable from a Fibre Modem LAN Port
to the furthest Module on that segment of LAN must not exceed 1500m
(1.5km).
(c)
No two Modules on the LAN shall be more than 15 “Delay Units” apart.
(d)
When used in a loop configuration, the Fibre optic loop may be no more
than 14 “Delay Units” in length.
The number of “Delay Units” is calculated as follows:
(a)
Add 1 Delay Unit for each Fibre Modem in the path.
(b)
Add 1 Delay Unit for each 1000 metres (1km) of Optical Fibre cable in
the path.
(c)
Add 1 Delay Unit for each 1350 metres (1.35km) of twisted pair LAN
cable in the path.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
82
42.
BMS & HVAC Interpreter
A field device shall be available that enables the system to interact with all
major building automation and HVAC communication protocols (over and
above the integration options built into the Control Module).
42.1
Operation
The device shall operate as a hardware level “black box” solution that
connects directly between the Control Module and the target automation
system.
OR
42.1.1
The device shall operate as a software level “black box” that allows interaction
between the system management software and the server(s) of third party
automation systems.
42.2
Deployment & Configuration
The Trans-Tech device shall be supplied as a custom factory-programmed
solution based on individual site requirements.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
83
43.
Hardware System LAN
43.1.1
The system hardware architecture shall be capable of using a mix of both
traditional RS-485 LAN and IP LAN between the Control Module and its field
modules.
43.1.2
Any part of the IP LAN must be capable of being routed across any IP
infrastructure, including wireless.
43.2
Encryption
The system IP LAN shall be encrypted using 128 bit AES encryption.
43.3
Electrical Isolation
The system shall provide electrical isolation between RS-485 LAN segments.
43.4
LAN Security
The system shall provide security detection across all RS-485 and IP LAN
segments in the event of network outages or module substitution.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
84
(This page has been left intentionally blank.)
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
85
Section 3 - Functional Spec
44.
General
44.1
Integration
Options for Security and Intruder Alarm, Access Control, Plant Monitoring,
Building Automation and Custom Control logic and timing functions shall be
provided within a single integrated system.
44.1.1
Security Alarm, Access Control, Plant Monitoring and Building Automation
functions shall operate independently or shall be integrated together to
achieve the system features required.
44.2
Host PC
The system must provide an option for connection to a host PC. The Host PC,
if utilised, shall provide system control and monitoring, event logging,
database maintenance and database backup. Full system functionality must
be maintained with or without the Host PC connected.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
86
45.
User Terminals
This section pertains to standard User Terminals. For Weatherproof Terminals
and Touchscreen Terminals, see the appropriate section.
45.1
Display
Programming options for each User Terminal shall provide the ability to
display any or all of the following information in plain text form:
(a)
Area status.
(b)
System status.
(c)
Alarm messages.
(d)
Alarm Review data.
(e)
Custom messages and/or Maintenance messages. Permanent or
displayed for specific time periods.
(f)
System information.
(g)
Current Time & Date of the Control Module.
45.2
Ease of Use
All User Terminal operations shall be Menu driven with user friendly text
prompts for each function or action to be performed.
45.3
On-line Help
All User Terminals shall include a dedicated HELP key that provides the User
with context sensitive help and instructions in plain text via the LCD.
45.4
Keypad Timeout
Users shall automatically be logged out from the User Terminal:
(a)
After no more than 15 seconds if logged in but no further key is
pressed.
(b)
After no more than 15 seconds if logged in and Area control screen
displayed.
(c)
After no more than 255 seconds if logged in and the Menu is entered.
45.5
User Duress
All User Terminals shall provide the ability to generate a Duress alarm when
any PIN Code is entered that is defined in system programming as a Duress
PIN Code. The Duress alarm shall identify the individual User and the User
Terminal and programming options shall allow the alarm to be logged and
reported as required.
45.6
Panic
All User Terminals shall provide the ability to generate a Panic alarm when a
designated key (e.g. the HELP key) is pressed three times is succession. The
Panic alarm shall identify the individual User Terminal and programming
options shall allow the alarm to be logged and reported as required.
45.7
Too Many PIN Tries (Keypad lockout)
All User Terminals shall provide the ability to generate a "Too many tries"
alarm and lock out the keypad for a specified period of time when a User fails
to enter a valid PIN code after a specified number of successive attempts.
45.7.1
Factory default settings shall provide a lockout time of 60 seconds after 5
attempts.
45.7.2
An enhanced programming option, when enabled, shall allow the number of
attempts to be programmable between 0 (no lockout) and 15.
45.7.3
Enhanced programming options, when enabled, shall also allow the following
timing parameters to be specified for each User Terminal from 1 to 255
seconds or from 1 to 255 minutes.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
87
(a)
The period in which the specified number of sequential incorrect
attempts must be reached.
(b)
The keypad lockout time.
45.7.4
The alarm shall identify the individual User Terminal and programming options
shall allow the alarm to be logged and reported as required.
45.8
System Access
Programming options shall be able to define the Menu options and functions
allowed, Areas displayed and controlled, and Message types displayed at each
individual User Terminal.
45.9
System Maintenance
All System programming and database maintenance shall be possible via
specified User Terminals without requiring connection to a host PC.
45.10
Fault Diagnostics
User Terminals shall provide fault messages in plain text on the LCD display to
assist with commissioning & troubleshooting.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
88
46.
Weatherproof User Terminals
This section pertains to Weatherproof Terminals. For Standard Terminals and
Touchscreen Terminals, see the appropriate section.
46.1
Invalid PIN
All Weatherproof Terminals shall provide the ability to generate an alarm when
a User fails to enter a valid PIN code.
46.1.1
The alarm shall identify the individual User Terminal and programming options
shall allow the alarm to be logged and reported as required.
46.1.2
Three unsuccessful PIN code attempts in succession shall cause the keypad to
be locked out for sixty seconds. An indicator lamp shall flash continuously
during this time.
46.2
Display
Programming options for each Weatherproof Terminal shall provide the ability
to display any or all of the following information via indicator lamps:
46.3
46.4
(a)
Area status while logged on
(b)
System status
(c)
Alarm condition
Ease Of Use
All Weatherproof Terminals shall be easy to operate, requiring simple logon
procedure followed by a unique single button operation for the following
functions:
(a)
Toggle area on/off
(b)
Unlock door
(c)
Logoff
Keypad Timeout
Users shall automatically be logged out from the Weatherproof Terminal:
(a)
After five seconds of no keypad activity
(b)
Following a door unlock operation
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
89
47.
Touchscreen User Terminals
This section pertains to Touchscreen Terminals. For standard Terminals and
Weatherproof Terminals, see the appropriate section.
47.1
47.2
Display
Programming options for each Touchscreen Terminal shall provide the ability
to display any or all of the following information in plain text form:
(a)
Area status.
(b)
System status.
(c)
Alarm messages.
(d)
Alarm Review data.
(e)
Custom messages and/or Maintenance messages. Permanent or
displayed for specific time periods.
Ease of Use
All Touchscreen Terminal operations shall be Menu driven with user-friendly
pictorial icons and/or text for each function or action to be performed.
(a)
Keypad Timeout
Users shall automatically be logged out from the Touchscreen Terminal
after no more than 60 seconds if logged in and no further touches are
made.
47.3
User Duress
All User Terminals shall provide the ability to generate a Duress alarm when
any PIN Code is entered that is defined in system programming as a Duress
PIN Code. The Duress alarm shall identify the individual User and the User
Terminal and programming options shall allow the alarm to be logged and
reported as required.
47.4
System Access
Configuration options shall be able to define the layout and hierarchy of some
of the user screens in each Touchscreen Terminal, and whether a PIN is
required to access building automation functions.
47.5
Fault Diagnostics
Touchscreen Terminals shall provide fault messages in plain text on the
display to assist with commissioning & troubleshooting
47.6
Too Many PIN Tries
All Touchscreen Terminals shall provide the ability to generate a “too many
tries” alarm and lock out the Touchscreen for 60 seconds when a user fails to
enter a valid PIN code after 5 successive attempts.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
90
48.
Real-time Clock and Calendar Functions
48.1
The system shall provide a real-time clock and calendar facility for the control
of Time Programs and Time & Date stamping of Events in the Event Review
log.
48.2
Daylight Saving Adjustment (Summer Time)
The system shall provide programming options to cause the system to
automatically add one hour to the Real-time clock at the beginning of the
Daylight saving period, and automatically subtract one hour from the Realtime Clock at the end of the Daylight saving period. This option shall be
programmable up to 1 year in advance and shall allow programming of the
date and time that each action is to be executed.
48.3
Time Programs (Time Zones)
The system shall provide Time Programs that allow valid time periods and/or
restrictions to be specified for specific User operations, system functions and
automatic control of specific system entities.
48.3.1
A minimum of 8 Time Programs shall be provided, expandable to 96.
48.3.2
Each Time Program shall allow up to four separate time periods (sub-zones) to
be specified allowing different valid time periods to be provided for different
types of days. (e.g. Weekdays, Weekends and Holidays)
48.3.3
Each time period shall allow the Start Time and End Time to be specified in
Hours and Minutes in 24-hour format and shall allow the valid days of the
week to be specified and whether the time period is to be valid on dates
specified as Holidays.
48.3.4
Programming options shall be provided to allow any Time Program to be
qualified (validated and/or invalidated) by the current state of any entity
within the system (E.g. Area status, Input status, etc.) via a nominated
Auxiliary Output.
48.3.5
Time Programs shall be able to be utilised to disable and/or alter the following
system parameters according to the Time of Day and/or Day of the Week:
48.3.6
(a)
The level of access to the system for specific types of Users.
(b)
The Door access criteria for specific types of Doors.
(c)
Input processing requirements for specific types of Inputs.
Time Programs shall be able to be utilised to control the following system
entities according to the Time of Day and/or Day of the week:
(a)
Turn an Area or a List of Areas On and/or Off.
(b)
Turn an Auxiliary Output On and/or Off.
(c)
Turn an Auxiliary Output On for 1 to 255 seconds, or 1 to 255 minutes.
(d)
Unlock and/or Lock a Door or a List of Doors.
(e)
Free and/or Secure a Floor or a List of Floors.
(f)
Trigger a test report to a Central Monitoring Station.
48.4
Holidays
The system shall provide for a minimum of 8 Holidays to be defined,
expandable to 32. Holidays shall be programmable up to 1 year in advance
and shall allow either one specific date to be programmed, or a date range
defined with a Start Date and End Date.
48.5
Custom Messages & Maintenance Messages
The system shall provide an option to display text messages of up to 32
characters on specified User Terminals either permanently, on a specific date
or for other specific time periods.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
91
48.5.1
The messages may be used to display a Helpdesk phone number, to indicate
that routine maintenance is due or other messages periodically required.
48.5.2
A minimum of 5 custom messages shall be provided, expandable to 32.
48.5.3
The messages shall be prioritised with Message 1 being the lowest priority and
the highest numbered message being the highest priority. Alarm messages
and system messages shall always take priority over any custom message.
48.5.4
A programming option shall be available for each message to activate a
specified Auxiliary Output while the message is valid.
48.5.5
A programming option shall be available to allow the use of an Auxiliary
Output to qualify the validity of a message. A message will become valid when
the Auxiliary Output is ON and is invalid when the Auxiliary Output is OFF.
48.5.6
A diagnostic programming option shall be available to check the Control
Module memory when the diary event becomes valid.
48.6
Clock Adjustment
The system shall provide an option to adjust the clock synchronization for
countries where the AC mains frequency is 60 Hertz.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
92
49.
Database
49.1
Expansion and Configuration
The database shall provide for expansion via different Memory size options.
Within each Memory size available, the installer shall be able to choose from
several standard configuration options to best utilise the available memory for
the particular application.
49.2
Database Structure
The database shall provide the ability to define multiple items and operations
in the form of programming Lists, Types and Groups to simplify programming
when multiple items are assigned or controlled and when common sets of
permissions and operations are assigned to multiple entities, e.g. Users,
Doors, Zone Inputs and Areas.
49.3
Dimensions
The database shall allow for a minimum of nnn [Entity], expandable to nnn.
Entity
Minimum of
Expandable to
User PIN codes
User names
Card Users
50
50
50
User Types
User RF Fobs
Areas
Doors
Lift Cars
8
10
8
4
3
Time Programs
Event Review Log
User Terminals
General purpose Zone
Inputs
Total LAN Modules
8
300
8
64
4096
4000
24,576 (up to 53,249 with special
custom memory configuration)
250
100
250
240
16 (up to 32 with special custom
memory configuration)
96
6500
99
2064
16
250
49.4
Text Names
The system database shall provide programmable text descriptions for all
Inputs, Areas, Users, User Types, TimeZones, Holidays, Groups, Doors, Area
Lists, Door Lists, Telephone Numbers and User controlled Auxiliaries.
49.4.1
Each individual Text entry shall be fully programmable with a minimum of 16
characters. A minimum of 24 characters shall be provided for Input names.
Systems using a library of pre-programmed words will not be acceptable.
49.5
Programming Defaults
The database shall provide a selection of basic default settings to simplify
programming.
49.6
Programming via User Terminals
All System programming and database maintenance shall be possible via
specified User Terminals without requiring connection to a host PC. Users shall
access programming menus and options via either entering a valid PIN code or
presenting a valid Card to a proximity reader connected to a Single Door or 2Door Access Module equipped with V5.0 Firmware or later.
49.6.1
Programming and editing the database from the LCD Terminal shall be via a
spreadsheet style menu allowing the User to select the next or previous item
to program and/or the next or previous option to program with a single
keystroke. A facility shall also be provided to jump to other relevant
programming options when required.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
93
49.6.2
The system shall provide a means of quickly locating items when
programming or editing the database via the User Terminal. Items shall be
able to be located by number or by text name via the ability to enter the first
letter of the name on the keypad in conjunction with “Up” and “Down” search
keys.
49.7
Installer Programming via PC
Software shall be available to allow the Installer full database programming
and editing either On-line or Off-line. However, programming changes shall
not be allowed on communications tasks that are currently active.
49.7.1
The software shall provide an Upload / Download facility to allow the full
system database to be transferred freely between the Control Module and the
PC via PSTN dialler line, direct RS232 connection or TCP/IP Ethernet network.
49.7.2
The Software application shall be password protected and in addition a
separate login code must be provided for connection to the Control Module.
49.7.3
The PC software shall also provide control of system entities and monitoring of
the Event Review log.
49.7.4
Programmable operator password levels shall be provided to ensure security
and allow operators to be restricted to the functions and databases that are
relevant to their role.
49.7.5
An option to enable a "Callback" facility shall be provided such that remote
login will require the remote operator to call the system, disconnect, then wait
for the system to call back on a pre-defined telephone number for added
security.
49.7.6
A more comprehensive System Management Software application shall be
available for continued management of the system by the customer.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
94
50.
User Database
50.1
PIN Code and/or Card Users
The system shall allow the following parameters to be specified individually for
up to 4096 separate Users:
(a)
User name of up to 16 characters.
(b)
User Type that defines permissions for: Operations allowed, Area/s to
turn On, Area/s to turn Off, Doors/Lift, Cars/Floors to access, Outputs to
control and any Time restrictions.
(c)
PIN code of up to 8 digits.
(d)
Access Card details.
(e)
Expiry Date and/or Time option.
(f)
User tenancy option for defining ability to program other Users.
50.1.2
An option shall be available to force user PIN codes to be six digits in length.
50.1.3
An option shall be available to define permission of control for a particular
Area for a User. This shall be User-specific rather than User Type-specific. A
system option shall be provided to allow the installer to disable the ability to
assign or edit this field if required.
50.1.4
Special options shall be available to define permission of access to a particular
door or a list of doors for each User. This shall be User-specific rather than
User Type-specific. A system option shall be provided to allow the installer to
disable the ability to assign or edit this field if required.
50.2
Card only Users
The system shall provide for an additional 24,576 User ID numbers that allow
the following parameters to be specified:
50.3
(a)
User Type that defines permissions for: Operations allowed, Area/s to
turn On, Area/s to turn Off, Doors/Lift Cars/Floors to access, Outputs to
control and any Time restrictions.
(b)
Access Card details.
(c)
Special options shall be available to define permission of access to a
particular door or a list of doors for up to 20,904 Users. This shall be
User-specific rather than User Type-specific. A system option shall be
provided to allow the installer to disable the ability to assign or edit this
field if required.
User RF Fob
The system shall provide up to 100 RF Fobs for 100 Users. Each RF Fob shall
be registered to a single User with each button on the RF Fob being fully
programmable to perform either one of the following functions:
(a)
Turn a nominated Area On
(b)
Turn a nominated Area Off
(c)
Turn a nominated Area List On
(d)
Turn a nominated Area List Off
(e)
Turn a nominated Auxiliary Output On
(f)
Turn a nominated Auxiliary Output Off
(g)
Toggle Auxiliaries On and Off
(h)
Generate an Alarm on a nominated Zone Input
(i)
Qualify a Zone Alarm Input
(j)
Qualify an Auxiliary Output
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
95
50.4
50.5
User Types
The following parameters shall be able to be specified separately for up to 250
different types of Users:
(a)
User Type name of up to 16 characters.
(b)
Time restrictions.
(c)
Areas allowed to turn On.
(d)
Areas allowed to turn Off.
(e)
User operations allowed. (Remote Access, Isolate Inputs when arming,
Timed Area control, Cancel Hold-up alarms, Cancel Sirens, Acknowledge
all alarms, Turn off Tamper monitoring and Reset latched alarms.)
(f)
Menu options allowed.
(g)
Doors, Lift Cars and Floors allowed to access.
(h)
Longer Door/Lift access time. (For disabled Users)
(i)
Dual User and Anti-Passback permissions and over-ride options.
(j)
User Ranking for permission to program other Users.
(k)
Auxiliary Outputs allowed to control.
Visitor Registration
The system shall allow programming of temporary Users such that a PIN Code
and/or Card issued to a User can be programmed to:
(a)
Be cancelled after a single use. [e.g. Card/PIN code issued at gate
house for one-off access to front door]
(b)
Expire at a specific Date and/or Time of Day. [e.g. Card/PIN code
issued to tradesperson]
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
96
51.
Event Review Logging
51.1
Event Review Log Capacity
The system shall maintain a Review log of all system activity of a minimum of
300 Events with options to expand the Review log up to 6500 events.
51.2
Access to Event Review Log
The full Event review log shall be accessible to authorised Users when logged
on to a User Terminal via a Menu option.
51.2.1
The full Event review log shall be accessible to authorised Operators via
optional Management software installed on the Host PC.
51.3
Quick Access to Alarm Review Log
The system shall provide an option for Quick Alarm Review at User Terminals.
If enabled the option shall be accessed with no more than two key presses
and shall not require the User to logon to the Terminal with a PIN code.
51.4
Detail
The system shall have a Review log option to temporarily provide the installer
with a detailed review of all processes and decisions made and all activity that
occurs in the system as an aid in de-bugging system programming and
commissioning the system.
51.5
Event Review Attributes
All Events shall be time and date stamped with Month, Date and Time,
accurate to 1/10ths of a second resolution and shall be categorised for basic
search facilities and filtering via the User Terminal. The following filter
categories shall be provided:
(a)
Alarms/Tampers/Restores
(b)
Reports
(c)
Auxiliary On/Off
(d)
Siren On/Off
(e)
User Logon/Logoff Operations.
(f)
Area On/Off
(g)
Isolates / De-Isolates
(h)
Modules (LAN)
(i)
General System messages
(j)
Time messages
(k)
Detail
(l)
Communications
(m)
Lifts
(n)
Cards
(o)
Errors
51.6
Display options shall be available allowing the display of Events in Full Text or
Abbreviated Text or Full Text + Abbreviated Text (for “Xmit and Input changes
of state” Events) or Raw Review Data on a User Terminal.
51.7
Printer (directly connected to Control Module)
The system shall have an option to connect a printer via a serial RS232
connection. The printer shall print Review log Events in real-time. Printer
options shall allow Review log Events to be filtered such that Events sent to
the printer can be limited to any number of the categories listed above in
“Review attributes”.
51.7.1
A special area filter shall be available to specify a list of Areas such that only
events related to the Areas on the list will be sent to the printer.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
97
51.8
Event Review Log Management
The system programming shall provide options for each Input and Auxiliary
Output that allow the installer to specify that particular non-critical events are
not to be saved to the Review log, thereby preserving memory space for more
important events as required.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
98
52.
Remote Monitoring (Off-site communications)
52.1.1
Central Station Reporting
The system shall provide options for reporting alarms and other information as
required to a remote and/or local Central Monitoring Station.
52.1.2
Initially, the system shall be programmed to report to [Monitoring Company]
utilising [Reporting format] as the primary format. Backup reporting shall be
programmed to report to [Monitoring Company] utilising [Reporting format] as
the Backup reporting format.
52.2
Primary Reporting Formats
The client’s future monitoring needs may change. As a minimum, the system
must support the following primary reporting formats:
52.3
(a)
Contact ID dialler via PSTN line.
(b)
IRfast dialler via PSTN line.
(c)
4+2 dialler.
(d)
Securitel. (Australia only)
(e)
Polled IP via GPRS
(f)
Polled IP via Ethernet
(g)
Polled IP via dial-up ISP
(h)
EarthNet Direct Line. (V1 to V4.5 firmware)
(i)
Contact ID via GSM Modem. (V4.06 firmware or later)
(j)
Text alarm messaging with optional programmable acknowledgement
time via GSM SMS (Short Message Service)
(k)
8 Pin STU (Subscriber Terminal Unit). Note that the STU must have
physical Inputs capable of receiving the Pin data from the Security
system via Auxiliary Outputs or Relay Outputs.
(l)
SIA dialler (V5 firmware or later)
(m)
System Management Software as Alarm Forwarding Service
Backup Reporting Formats
The system shall provide the option for backup reporting in the following
format options:
(a)
Contact ID dialler via PSTN line.
(b)
IRfast dialler via PSTN line.
(c)
4+2 dialler
(d)
Polled IP via GPRS
(e)
Polled IP via Ethernet
(f)
Polled IP via dial-up ISP
(g)
Contact ID via GSM Modem. (V4.06 firmware or later)
(h)
Text alarm messaging with optional programmable acknowledgement
time via GSM SMS (Short Message Service)
52.4
Multiple Central Monitoring Stations
The system shall be capable of reporting to more than one primary Central
Monitoring Stations.
52.5
Dial-up Reporting
For each Central Monitoring Station that the system will report to via a PSTN
dialler line, programming Options shall provide for up to four Telephone
Numbers to be assigned that will be used in turn to attempt to establish the
connection.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
99
52.6
Dialling Sequence
Should the dial attempt on the primary telephone number fail, the system
shall utilise the other telephone numbers programmed for the communications
task, in sequence, to attempt to connect, up to the specified maximum
number of attempts. A suitable pause shall be inserted between each
attempt, but shall be no more than 120 seconds.
52.6.1
The number of dial attempts shall be programmable from 1 to 255, but when
programmed, must comply with Telecommunications authority regulations. A
default setting of 4 attempts shall be pre-programmed.
52.7
Remote Access
The system shall be capable of answering an incoming call from a remote PC
regardless of the reporting format used. Support for use of an external
modem is acceptable if the selected reporting format necessitates. (e.g.
Direct line formats)
52.8
8 Pin Communication Output
The system shall provide an option to activate Auxiliary Outputs for 8 different
types of alarms with Alarm Verification logic for “Intruder” alarms. These
Outputs shall be able to trigger Inputs on a third-party communication device,
e.g. an 8 Pin STU. This option shall satisfy UK ACPO requirements.
52.9
PSTN Line Monitoring and Testing
The system shall provide automatic PSTN line testing and shall monitor the
status of the line during any dial attempts. In the event of communications
failure with the Central Monitoring Station, the system shall display a
Communications Fail message on specified User Terminals and generate an
entry in the Event log that describes the specific problem for any of the
following conditions:
(a)
No Line detected.
(b)
No telephone number programmed.
(c)
Noisy Line.
(d)
Maximum dial attempts reached.
(e)
No acknowledgement.
(f)
Maximum on-line time exceeded.
52.9.2
Carrier Lost. (Modem formats)
52.9.3
Area Status Reporting
The system shall provide the following Area reporting features:
52.10
(a)
Area Open/Close by User ID.
(b)
Options to specify which Areas are reported.
(c)
Option to report a unique Client Code for each Area (Partition).
(d)
Options to allow Area (Partition) Open and Close reports to be sent for
each individual Area or as “General Open/Close” reports. (i.e. First to
Open / Last to Close)
(e)
Option to send “Area Still Open” (Late to Close) reports if a specified
Area is still Open when other Area/s are closed.
(f)
Option to send “Area 24 Hour Off” (Area Tamper monitoring Off) reports
when Tamper monitoring is turned Off in any Area.
Input Status Reporting
The system shall provide the following Input reporting features:
(a)
Alarm.
(b)
Tamper.
(c)
Isolate (Bypass).
(d)
Restore.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
100
(e)
Option to report multiple alarms on a single point. (“Multi-break”
reporting)
(f)
Option to cause reporting of a new alarm point to take priority over
multiple reports (multi-breaks) on an existing alarmed point. (Often
referred to as “Look-ahead” reporting)
(g)
Options to allow customisation of Contact ID point mapping to best
utilise the limited number of Contact ID points available in the format.
52.11
Alarm Routing
The system shall have the capacity to report alarm events of different types or
from different origins via different communications formats to different
locations.
52.11.1
For example:
(a)
Security alarms from one section or tenant go to ABC Control Room Ltd.
via dialler.
(b)
Security alarms from another section or tenant go to XYZ Alarm
Monitoring Ltd. via dialler or GSM modem.
(c)
All building plant alarms go to an engineer via an SMS message.
52.11.2
The system shall allow the same alarm to be processed by up to ten
communication tasks, with each task able to report in a different format to a
different location.
52.12
System Management Software Alarm Forwarding Service (Option)
The system shall have the ability to report any and all alarm events to its
permanently connected System Management Computer Server which, in turn
will forward the alarm event to the appropriate co-located Central Station
Automation Server in the appropriate communication format. In this way, a
System Management Server connected to a large number of Control Modules
on an Ethernet network can act as a cost-effective concentrator for alarm
transmissions.
52.12.1
The system shall implement true end-to-end alarm transmission
acknowledgement between the Control Module and the Alarm Automation
Server in the Central Station.
52.12.2
The system shall initiate a back-up communication task in the event that an
alarm message:
(a)
has not been acknowledged by the Automation Server within a specific
period of time.
(b)
if the maximum number of retries is reached.
(c)
if the System Management Server is unavailable of off-line.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
101
53.
Alarm Monitoring System
(Intruder Alarm system / Intruder Detection system)
53.1
Partitioning
Provision shall be made for partitioning the system into separate Areas for
individual programming, control, monitoring and reporting. A minimum of 8
Areas shall be available with options for up to 250 Areas. Each Area must
provide for a programmable 16-character name to be defined.
53.2
Area Control
Programming options shall allow for individual or multiple Area Off and On
(Open / Close) operations to be performed by Users, Inputs (e.g. Keyswitches), RF Fobs, Time Programs or Logic Programs and for Areas to be
controlled either singly, or as a group.
53.3
Entry Delay
The system shall provide an Entry Delay feature to allow authorised Users
sufficient time to enter the premises and make their way to the User Terminal
[or other device used to turn the Area Off such as Keyswitch, Card Reader,
etc.] before turning the relevant Area/s Off.
53.3.1
Programming options shall allow for an Entry Delay time to be programmed
for each Area from 1 to 255 seconds such that when an Area is On (Armed or
Closed) Zone Inputs defined as Entry Zones will not generate an alarm when
activated until after the Entry Delay has expired.
53.3.2
If the Area is turned Off before the Entry Delay timer expires, any alarms on
Entry Zones shall be ignored.
53.3.3
If the Area is still On after the Entry Delay timer expires, any alarms that
occurred during the Entry Delay time shall then be processed normally.
53.3.4
Programming options shall allow two types of Entry Zones to be defined such
that an Entry path can be defined:
(a)
Primary Entry Zones - when activated will start the Entry Delay timer
running if not already running, e.g. Reed switch on Entry Door/s or
PIR/s just inside the Entry Door/s.
(b)
Entry Zones - when activated will generate an alarm instantly if the
Entry Delay timer is not already running, e.g. Internal PIR/s that will
not be the first Zone Input/s activated on Entry.
53.4
Exit Delay
The system shall provide an Exit Delay feature to allow Users sufficient time to
exit the premises without generating an alarm after turning the relevant
Area/s On.
53.4.1
Programming options shall allow for an Exit Delay time to be programmed for
each Area from 1 to 255 seconds such that when the Area is turned On, Zone
Inputs defined as Exit Zones will not generate an alarm if activated during the
Exit Delay time.
53.4.2
When the Exit Delay timer has expired, any new alarms on Exit Zones shall
then be processed normally.
53.5
Auto Isolation
Programming options shall allow specified Zone Inputs to be automatically
isolated (bypassed) if un-sealed when the Area is turned On (Closed or
Armed).
53.6
Common Areas
A programming option shall allow a sub-Area to be defined for each Area to
allow automatic control of "common" Areas.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
102
53.7
Timed Area Control
An option shall be provided to define any Area to be “Timed Off” when turned
off (opened) by a User via a User Terminal or a Time Program or an Access
Control Card. The time period shall be programmable from 1 to 255 minutes
in 1-minute intervals and shall be defined separately for each Area to be
timed.
53.7.1
The system shall allow Area Timing operations to be enabled or disabled for
different types of Users such that an Area can be “Timed off” by some types of
Users and controlled normally by other types of Users.
53.7.2
When a timed Area is turned off by a User with Area timing operations enabled
or Time Program with Area timing operations enabled, the timer shall start.
On expiry of the timer the Area shall automatically return to the on state.
53.7.3
If an Area is currently timed off; a User with Area timing operations enabled
may perform an Area off operation at any time to re-start the timer.
53.7.4
If an Area is currently timed off; a User with Area timing operations disabled
may perform an Area off operation at any time to cancel the timer and
maintain the Area in the off state.
53.7.5
The system shall provide a warning via beepers in User Terminals for a period
of 255 seconds prior to the expiry of an Area timer to allow Users to exit the
premises or perform an Area off operation to re-start or cancel the timer.
53.8
Siren Operation
The system shall provide the following Siren control options:
53.9
(a)
Two Siren Speaker Outputs for “External” and “Internal” Sirens shall be
provided on the Control Module and all Zone Expansion Modules
supporting 16 or more Inputs.
(b)
"Instant", "Delayed" and "Backup" Siren Modes shall be defined
separately for the External and Internal Siren Outputs in each individual
Area.
(c)
A minimum of 4 different Siren Tones shall be available that can be
defined separately for different types of Alarms. (e.g. "Bell", "Sweep",
"Fire" & "Evacuation")
(d)
Siren tones shall also be defined separately for Input Alarm and Input
Tamper conditions.
(e)
Two programming options shall be available for setting Siren Time: up
to 200 minutes in 1-minute increments or up to 55 seconds in 1-second
increments.
(f)
Open circuit on any dedicated Siren Speaker Output shall activate a
system alarm.
(g)
The "Backup" Siren Mode shall cause the Siren Speaker to sound only
when the backup communication task is triggered, i.e. there is a
primary communication failure.
(h)
An optional Holdoff Timer shall be provided for Siren Speaker Outputs,
to delay the sounding after an alarm is triggered. This timer shall be
programmable from 0 to 127 minutes in 1-minute intervals. This timer
will expire immediately by entering a valid PIN code to turn OFF the
Area the alarm is attached to while the Timer is still running.
Auxiliary Outputs
Programming options shall provide for Auxiliary Outputs to be defined for each
individual Area to activate under the following conditions:
(a)
Entry Timer running
(b)
Exit Timer running
(c)
Siren
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
103
(d)
Area Close (Area On or Armed)
(e)
Tamper
(f)
Alarm
(g)
Isolate
(h)
User Count
(i)
Test mode active
53.10
Wireless Detection Devices
The system shall provide a LAN-based RF Expander Module to interface with
Visonic PowerCodeTM RF detection devices and CodeSecure™ RF Fobs. Each
RF Module shall support up to 32 RF detection devices with each system being
capable of registering up to 100 RF Fobs for 100 Users.
53.10.1
The system shall provide a LAN based RF Wireless Transceiver Module to
interface with Paradox Magellan™ RF detection devices and RF personal
transmitters (fobs). Each Module shall support up to 32 RF detection devices
with each system being capable of registering up to 100 RF fobs for 100 users.
53.10.2
The system shall have the ability to provide a 4-wire RS232 serial interface to
a Wireless Receiver (C&K SpreadNet® Receiver or Inovonics FA-400/MF
Receiver). The interface shall support up to 208 Wireless devices
[Please check with local distributors of C&K Systems products and Inovonics
products for communications authority approvals]
53.11
Input Processing
The system shall provide 16 already programmed default Input Processing
Types with options to support up to 64 different types.
53.11.1
Inputs may be assigned to more than one Area up to a maximum of 8 Areas.
53.11.2
Input processing shall be separately defined for each Area that an Input is
assigned to, e.g. a single entry hall PIR may be processed as a Burglary alarm
via one Area and control lighting via another Area.
53.11.3
Input Alarm (Unseal) and Seal states shall only be processed whenever an
Area that it is assigned to is On (Closed or Armed). Alarm monitoring will be
disabled in an Area whenever the Area is Off.
53.11.4
An input processing option shall allow the Input Alarm (unseal) and Seal
states to be processed regardless of the area state (i.e. “24 hour” processing)
for nominated input types.
53.11.5
All Alarm monitoring Inputs shall be supervised for the Tamper state 24 hours
a day. The Tamper state shall always be processed regardless of Area Status.
53.11.6
An Input processing option shall be available to “Latch” an alarm such that the
alarm message cannot be acknowledged by a User until the Input has
returned to the "Seal" condition e.g. plant alarms.
53.11.7
An Input processing option shall allow Pulse Counting to be specified for
individual Inputs, where the nature of the Input device or the installation
environment requires multiple “hits” to be recorded before registering an
Alarm (Unseal) condition. The count number and pulse count time window
shall be programmable on a per Area basis.
53.11.8
An Input processing option shall allow delay in reporting an Input alarm with a
programmable timer from 1 to 255 seconds in 1-second increments.
53.11.9
An Input processing option shall allow an Input to cancel the running of an
Exit Delay Timer in an Area when the Input state changes from Seal to Alarm
(e.g. when a Push Button is pressed).
53.11.10
Input processing options shall allow the "Pin Type" for 8 Pin communication
format to be specified for individual Inputs with Verify Group logic when
applicable.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
104
53.11.11
An Input processing option shall allow SMS alarm messages to be sent to one
or more telephone numbers with or without acknowledgement.
53.11.12
An Input processing option shall allow SIA alarm messages to be sent to one
or more Central Monitoring stations when an alarm condition takes place.
53.11.13
The following parameters shall be defined separately for each type of Input to
be processed:
53.12
(a)
Input States to be processed. These shall include Alarm (Unseal),
Tamper, Primary Entry Delay, Entry Delay (Hand-over), Exit Delay and
Pulse Count.
(b)
§
Input conditions to be reported. These shall include Alarm
(Unseal), Tamper, Isolated (Bypassed), Restored, Alarm during Entry
Delay and Alarm during Exit Delay.
(c)
Contact ID Event Code. (Standard default Event Codes shall apply if not
specified)
(d)
Area Auxiliary Outputs to activate.
(e)
Alarm Siren Tone and Tamper Siren Tone.
(f)
Siren Isolate (lockout) and Siren Re-trigger options.
Defaults
A set of default Input processing options shall be available to simplify system
programming and shall provide for processing of the following basic Input
types:
Alarm Input Type
Example
Burglary Zone.
Internal PIR.
Door Reed on Fire Door or Internal Door.
Door Reed on Entry Door.
PIR inside Entry Door.
Burglary Primary Entry/Exit Zone.
Burglary Entry/Exit Zone. (Hand-over
Zone)
Local Silent.
Fire Zone.
Duress
Automation
System Tamper.
System Silent.
System LAN problems.
System Local.
Access Local.
Access Alarm.
Access Silent.
53.13
Smoke detector / Heat detector.
Keypad Duress alarm. (When a "Duress"
PIN Code is entered)
Duress or Silent Panic button.
Function Zone Inputs
Switches for control of lighting systems.
Cabinet Tamper / Siren Tamper.
AC Fail / Low Battery / Plant alarms to
report /
Film Low/Film Out.
Module Off-line.
Line fault / Comms fail / Local Plant
alarms.
Too many PIN code attempts / Illegal
Card.
Door Forced.
Door Open Too Long. (Door Held)
Alarm Messages
Programming options shall allow the installer to define which types of alarm
messages are displayed on each User Terminal.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
105
54.
Input Testing
54.1
Area Pre-Arm Testing
Whenever a User attempts to turn an Area On at a User Terminal or using 3
Badges-Arming or Arm Button-Arming at a Single Door or 2-Door Access
Module, the system shall perform a test on all Inputs in that Area to ensure
that they are in the Sealed state in order to minimise false alarms when the
Area is turned on.
54.1.1
Programming options shall be provided to allow specific Zone Inputs to be
excluded from the test for Sealed state if they are expected to be Unsealed
when the Area is turned On, e.g. a PIR that detects movement near the User
Terminal, a Reed Switch on an Open Entry Door, etc.
54.1.2
This programming option shall only be utilised on Inputs defined as Exit Zones
in any Area that has an Exit Delay time defined and that are expected to be in
the Sealed state before the Exit timer expires.
54.2
Automatic Input Testing
Programming options shall be provided for each individual Zone Input, to allow
automatic testing of appropriate detection devices.
54.2.1
Automatic Input testing shall be performed on specified Zone Inputs when the
Area is turned On and shall ensure that each detection device is operational by
checking that the Input has gone into the Alarm state at least once since the
last time that the Area was turned On. No additional User operation shall be
required.
54.2.2
This programming option shall only be utilised on Inputs that are activated
regularly in the period during which the Area is Off (Disarmed or Open), e.g.
PIRs and Door Reeds that are activated during the normal course of a day.
This option would not be utilised on devices such as Smoke Detectors, Seismic
Detectors, Roof Space PIRs, Panic/Duress buttons, etc.
54.2.3
Programming options shall provide for a Test Fail condition to be logged and
activate auxiliary Outputs, alarms, central station reports, etc. as required.
54.3
Polling of RF Zone Inputs
As to maintain system integrity, every Visonic and Paradox RF Zone Inputs
registered on the system shall be monitored via a programmable polling time.
If any Zone Input fails to report within the polling time to the RF Expander
Module it is registered to, a System Input shall be generated by the RF
Expander Module to report the situation.
54.4
Area Walk Testing
Programming options shall be provided for each individual Area database to
provide Walk testing of specified Zone Inputs in the Area.
54.4.1
Programming Options shall provide for Walk testing to be commenced by
either or both of the following methods:
(a)
Manually by an authorised User via a User Terminal Menu option.
(b)
Automatically when an Area is being turned On (Area Pre-Arm Walk
Test).
54.4.2
Walk testing shall force the User to test that each specified Zone Input is
operational by activating the device connected to the Zone Input during the
maximum test time allowed, e.g. Walking past a PIR, Opening and Closing a
Door, Pressing and Releasing a Panic Button, etc.
54.4.3
Area programming options shall allow for Zone Inputs already tested via the
Automatic Input Testing to be excluded from the Walk Test.
54.4.4
The maximum test time shall be programmable for each Area from 1 to 20
minutes in 5 second increments.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
106
54.4.5
Programming options shall provide for an Area Pre-Arm Walk Test Started
and/or Area Pre-Arm Walk Test Fail condition to be logged and activate
Auxiliary Outputs, Alarms, Central Station Reports, etc. as required.
54.4.6
Area programming options shall allow an Auxiliary Output to be activated
during Walk Testing to:
(a)
Enable testing of devices that provide a test Input connection such as
Smoke, Glass-break and Seismic detectors.
(b)
Provide audible and/or visual indication of Walk Test mode active.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
107
55.
Duress Alarm Management
55.1
User PIN Code Operation
A User, when forced to perform operations on the system under Duress shall
have the ability to enter a Duress PIN code that will trigger a Duress alarm
while still providing the User with normal or limited system operation.
55.2
Duress PIN Code/s
The system shall provide for one common “Duress Code” to be programmed
for all Users that will trigger a Duress alarm while providing the User with a
pre-defined level of system operation.
55.2.1
The system shall individually identify the User Terminal where the Duress
Code is entered in the Review log and to the Central Monitoring Station and/or
Host PC Management Software.
OR
55.2.2
The system shall provide for a number of common “Duress Codes” that can be
issued to different types of Users. Each Duress Code shall trigger a Duress
alarm while providing the User with a pre-defined level of system operation
according to their level of system access, physical location or department, etc.
55.2.3
The system shall individually identify the Duress Code used and the User
Terminal where the Duress Code is entered in the Review log and to the
Central Monitoring Station and/or Host PC Management Software.
OR
55.2.4
The system shall provide for any User to increment the last digit of their
normal PIN code by a value of 1 to indicate a Duress condition while still
identifying the individual User, e.g. Normal PIN = 12345. Duress PIN =
12346.
55.2.5
The system shall individually identify the User and the User Terminal where
the Duress Code is entered in the Review log and to the Central Monitoring
Station and/or Host PC Management Software.
55.3
Duress Alarm Messages
The system shall restrict Duress Alarm messages to appear on specified User
Terminals only.
OR
55.3.1
The system shall not display Duress Alarm messages on any User Terminal.
55.4
Duress Alarm Processing
The full range of Input processing options shall be available for Duress Alarms
to provide for future additions and/or changes to Duress Alarm monitoring.
55.5
Discreet Processing
Programming options shall be provided to allow for Duress Alarms to be
logged and/or reported and activate any Outputs required with no local
indication of the alarm condition via User Terminal displays or other audible or
visible devices.
55.5.1
A default Input processing option named "Duress" shall be available that
meets these requirements.
55.6
Mimic Panel
A mimic panel shall be installed in…that shall display individual Duress Alarms
for each User Terminal in the system.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
108
56.
Panic Alarm Management
[NOTE: All Input processing features described in this application are
standard features that can also be utilised in the monitoring and processing of
any type of Zone Input in the system as required]
56.1
Panic Buttons
Momentary Push-button switches shall be installed in specified locations and
individually wired to Inputs on appropriate system Modules for signalling a
“Panic” condition.
56.2
Input De-bounce Time
Programming options for momentary Panic Button Inputs shall allow the Input
de-bounce time to be programmed separately for each Input from 5
milliseconds to 1250 milliseconds (1.25 seconds).
56.2.1
(To provide the optimum de-bounce value for the required button sense time
while still maintaining immunity to noise.)
56.2.2
[Programmable De-bounce Time is available on Concept Mini Expander
Modules only.]
56.3
Panic Button Operation
When activated, Panic Buttons shall trigger a Panic Alarm that individually
identifies the Input activated in the Review log and to the Central Monitoring
Station and/or Host PC Management Software.
56.4
Delayed Panic Alarm Reporting (False Alarm Management)
An option shall be available for each Area in which Panic Inputs are monitored
to delay the reporting of the Alarm condition for a programmable period of up
to 255 seconds in 1-second increments. Activation of local alarm annunciation
and actions shall not be affected by the delay.
56.4.1
User Terminals shall display a discreet prompt (e.g. “Enter Code”) allowing
authorised Users to enter their PIN code and cancel the Panic alarm during the
delay period.
56.4.2
The registering of a specified number of Panic Input activations shall cancel
the reporting delay and immediately report the Panic alarm/s. The number of
activations required shall be programmable from 2 to 15.
56.5
User Terminal Panic Operation
Pressing the <HELP> key on any User Terminal three times in succession shall
trigger a Panic Alarm that individually identifies the User Terminal in the
Review log and to the Central Monitoring Station and/or Host PC Management
Software.
56.6
Panic Alarm Messages
The system shall display Panic Alarm messages on all User Terminals.
OR
56.6.1
The system shall restrict Panic Alarm messages to appear on specified User
Terminals only.
OR
56.6.2
The system shall not display Panic Alarm messages on any User Terminal.
56.7
Panic Alarm Processing
The full range of Input processing options shall be available for Panic Alarms
to provide for future additions and/or changes to Panic Alarm monitoring.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
109
56.8
Discreet Processing
Programming options shall be provided to allow for Panic Alarms to be logged
and/or reported and activate any Outputs required with no local indication of
the alarm condition via User Terminal displays or other audible or visible
devices.
56.9
Mimic Panel
A mimic panel shall be installed in…that shall display individual Panic Alarms
for each Panic Button and User Terminal in the system.
56.10
Hold-up Alarm and/or Suspicion Alarm Management
[NOTE: All Input processing features described in this application are
standard features that can also be utilised in the monitoring and processing of
any type of Zone Input in the system as required]
56.11
Hold-up and/or Suspicion Buttons
Momentary Push-button switches shall be installed in specified locations and
individually wired to Inputs on appropriate system Modules for signalling a
“Hold-up” or "Suspicion" condition.
56.12
Input De-bounce Time
Programming options for momentary Hold-up button Inputs shall allow the
Input de-bounce time to be programmed separately for each Input from 5
milliseconds to 1250 milliseconds (1.25 seconds).
56.12.1
(To provide the optimum de-bounce value for the required button sense time
while still maintaining immunity to noise.)
56.12.2
[Programmable De-bounce Time is available on Concept Mini Expander
Modules only]
56.13
Button Operation
When activated, buttons shall trigger an Alarm that individually identifies the
Input activated in the Review log and to the Central Monitoring Station and/or
Host PC Management Software.
56.14
Delayed Hold-up Alarm Reporting (False Alarm Management)
An option shall be available for each Area in which Hold-up Inputs are
monitored to delay the reporting of the alarm condition for a programmable
period of up to 255 seconds in 1-second increments. Activation of local alarm
annunciation and actions shall not be affected by the delay.
56.14.1
User Terminals shall display a discreet prompt (e.g. “Enter Code”) allowing
authorised Users to enter their PIN code and cancel the Hold-up Alarm during
the delay period.
56.14.2
The registering of a specified number of Hold-up Input activations shall cancel
the reporting delay and immediately report a Hold-up Alarm. The number of
activations required shall be programmable from 2 to 15.
56.15
Bandit Screen Activation
Hardware and programming options shall be provided to allow activation of
Hold-up Buttons to operate an Auxiliary Output on the same system Module
within 20milliSeconds of the button activation for the purpose of triggering
bandit screens.
56.15.1
[Only available on Concept Mini Expander Modules]
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
110
56.16
Alarm Messages
The system shall display Hold-up and/or Suspicion Alarm messages on all User
Terminals.
OR
56.16.1
The system shall be capable of restricting Hold-up and/or Suspicion Alarm
messages to appear on specified User Terminals only.
OR
56.16.2
The system shall not display Hold-up and/or Suspicion Alarm messages on any
User Terminal.
56.17
Hold-up Alarm and/or Suspicion Alarm Processing
The full range of Alarm monitoring system Input processing options shall be
available to provide for future additions and/or changes to Hold-up and
Suspicion Alarm monitoring.
56.18
Discreet Processing
Programming options shall be provided to allow for Hold-up Alarms and/or
Suspicion Alarms to be logged and/or reported and activate any Outputs
required with no local indication of the alarm condition via User Terminal
displays or other audible or visible devices.
56.19
Mimic Panel
A mimic panel shall be installed in… that shall display individual Hold-up
Alarms and/or Suspicion Alarms for each Button in the system.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
111
57.
Door Access Control
57.1
Door Access Operations
The system shall be capable of providing User Door Access Control via any of
the following operations:
(a)
Presentation of a Card (or other form of User ID token) at the Door
Reader assigned to the Door.
(b)
Entry of a PIN code only at the User Terminal assigned to the Door.
(c)
Entry of a PIN code at a Wiegand keypad assigned to the Door.
(Vandal-proof and/or Scrambling keypad)
(d)
Presentation of a Card at the Reader PLUS entry of a PIN code at the
User Terminal assigned to the Door within a specified time period.
(e)
Presentation of a Card PLUS entry of a PIN code at a Proximity Reader
with built-in keypad assigned to the Door within a specified time period.
(HID5355 and Motorola ARK-501 only)
(f)
Presentation of a Card PLUS entry of a PIN code at a 26 Bit Wiegand
Keypad wired in parallel with a 26 Bit Wiegand Proximity Reader (the
PIN code must be 5 digits in length and not greater than 65,536;
available with Single Door or 2-Door Access Module with V5.0 Firmware
or later only).
(g)
Presentation of a Card at the Reader OR entry of a PIN code at the User
Terminal assigned to the Door.
(h)
Activation of a Button, other Input device such as a Movement detector
or PE beam designated as an Entry or Exit Input.
(i)
Activation of the <OK> key on a User Terminal assigned to the Door.
57.1.2
The mode of Access shall be programmed separately for the Entry operation
and Exit operation on each Door in the system. Options shall be provided to
allow the mode of Entry Access and/or Exit Access at any Door to be altered or
cancelled according to a Time Program, Area Status (On, Off or Alarm),
Keyswitch Input or other mechanism as required.
57.1.3
The full range of Door Access Control operations listed above that utilise a
Card shall be available on all Doors in the system regardless of the type of
Door Access Module installed.
57.1.4
Door Un-lock and Lock operations shall also be available to authorised Users
via a Door Control Menu when logged on to a User Terminal. The User
Terminal display shall provide text prompts for the User to specify the Door to
control and the operation required.
57.2
Door Timers
“Door Un-lock Time” and “Maximum Door Open Time” shall be programmed
separately for each Door in the system from 1 to 255 seconds in 1-second
increments.
57.2.1
Intelligent Door Controllers shall provide an option via a DIP switch setting to
process the ‘Door Un-lock time” in 100 millisecond increments.
57.2.2
This option shall be provided to cater for 3rd party access devices such as
turnstiles that require an un-lock command consisting of a short pulse.
57.2.3
Programming options shall provide extended Door Access times for disabled
Users.
57.3
Access Alarms
The system shall provide the ability to activate the following alarms on any
Door in the system:
(a)
Door Forced. When the Door is secure and is opened without a valid
un-lock command.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
112
(b)
Door Held (Door Open Too Long). If the Door is opened after a valid
un-lock command and remains open longer than the specified
"Maximum Door Open time".
57.3.2
The full range of Input processing options shall be available to log Access
alarms and activate any Messages, Sirens, Outputs, Central Station Reports,
etc. as required.
57.3.3
Programming options shall allow two stage Door Held (Door Open Too Long)
alarm processing to be enabled for each Door such that a local Module Alarm
can be activated for a period equivalent to the maximum Door Open Time to
allow the Door to be closed before a system Door Held alarm is generated.
57.3.4
Programming options shall allow for a separate Tongue Sense Input to be
monitored for each Door and utilised in “Door Forced” and “Door Held” alarm
processing.
57.4
Review Log
A Review Log entry shall be generated for every Door Access operation. Each
Review log entry shall be time and date stamped with Month, Date and Time,
accurate to 1/10ths of a second resolution and shall identify the User, the
Mode of Access and the Door controlled.
57.5
Alarm System Control
Programming options shall be provided to allow an Area to be associated with
the Inside and/or Outside of any Door to allow integration of Access Control
and Alarm System Control.
57.5.1
Programming options shall be provided to allow authorised Users to
automatically turn off the alarm system Area that they are entering when
gaining access through a Door.
57.5.2
Programming options shall be provided to allow authorised Users to
automatically turn off an Area associated with the particular User when
gaining access through a Door.
57.5.3
Programming options shall be provided to allow authorised Users to turn on
the alarm system Area that they are leaving via the Entry Reader or Exit
Reader associated with the Door.
57.5.4
To ensure that an Area on operation is the Users intended action; the
operation shall differ from a normal Door Access operation. Any of the
following options are acceptable:
(a)
Activation of an “Arming button” while the card is presented.
(b)
Three presentations of the same card within 5 seconds.
57.5.5
Programming options shall be provided to allow Alarm System Control
operations at any Door to be altered or cancelled according to a Time
Program, Area Status (On, Off or Alarm), Keyswitch Input or other mechanism
as required.
57.6
Dual User Access
An option for Dual User access shall be able to be specified separately for
Entry and Exit Readers on any Door where the function is required.
57.6.1
The system shall provide the ability to define specific types of Users as “Dual
User Providers”, i.e. a User defined as a “Dual User Provider” must provide the
first User Card and/or PIN code at Doors defined as Dual User Access.
NOTE: The system shall also have the ability to provide for any two Users to
gain access at Dual User Access Doors by simply defining all types of Users as
“Dual User Providers”.
57.6.2
Dual User Access shall be compatible with Card access, PIN code access or
Card & PIN access operations.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
113
57.7
Free Access - Enable and/or Disable
Programming options shall allow any individual Door or any group of Doors to
be set to Free Access mode and/or Re-locked via a Time Program, Input (e.g.
Key-switch), Area Status (on, off or alarm), User Terminal operation, Logic
Program or other mechanisms as required.
57.8
Door Interlocking
Programming options shall allow Doors to be interlocked together such that a
valid User will not be granted access at a Door unless all other Doors in the
interlock group are currently both locked and closed.
57.8.1
Interlocking shall be processed globally across the system allowing any Doors
to be included in Interlock logic.
57.8.2
Programming options shall allow Door Interlock logic to be qualified with Time
Programs, Area Status (On or Off), Input state or Auxiliary state as required.
i.e. A User will not be granted access at a Door unless all other Doors in the
interlock group are currently both locked and closed and the qualifying
factor/s are met, e.g. a specified TimeZone is valid, a particular Area is Off, a
Keyswitch Input is sealed, etc.
57.8.3
Door Interlocking shall be available on all Doors in the system regardless of
the type of Door Access Module installed and shall not require any additional
detectors or wiring apart from that associated with standard Door control and
monitoring.
57.9
Anti-Passback
The system shall provide options for Anti-Passback logic by maintaining a
record of the current location of each User. An Anti-Passback violation shall
be logged if the User attempts to:
(a)
Gain access through a Door to the Area that the system currently
records them in, i.e. the Card has been “passed back” to another User.
(b)
Access a Door from an Area other than the Area that they are currently
recorded in.
57.9.2
The Anti-Passback feature shall be available on all Doors in the system
regardless of the type of Door Access Module installed.
57.9.3
Three modes of Anti-Passback processing shall be provided defined as “Soft
Anti-Passback”, “Hard Anti-Passback” and “Timed Anti-Passback”. The AntiPassback mode (None, Soft, Hard or Timed) shall be defined separately for
Entry and Exit operations on each Door and programming options shall be
provided to cancel or alter Anti-Passback modes according to a Time Program.
(a)
Entry and/or Exit operations defined as “Soft Anti-Passback” operation
shall log Anti-Passback violations but shall still grant access through the
Door.
(b)
Entry and/or Exit operations defined as “Hard Anti-Passback” operation
shall deny access through the Door and log the Anti-Passback violation.
(c)
Entry and/or Exit operations defined as “Timed Anti-Passback” operation
shall deny access through the Door and log the Anti-Passback violation.
Amnesty will automatically be granted when the anti-passback timer
expires for that user.
57.9.4
Anti-Passback shall be processed globally across the system allowing any or all
Doors to be included in Anti-Passback logic.
57.9.5
An Anti-Passback “Amnesty” function shall be available to reset all Users to
“No Area” such that Anti-Passback processing will be re-started. Programming
options shall provide for the “Amnesty” function to be triggered by a User
operation, Time Program, Input (Keyswitch, etc.), Area status, or other
operation as required.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
114
57.10
User Counting
The system shall provide programming options to monitor the number of
Users present in any nominated Areas entered and exited via Accesscontrolled Doors.
57.10.1
The system shall allow the Installer to select whether Area User Count is
saved to review or not.
57.10.2
Programming options shall provide for automatic Area Off and On (Open and
Close) operations based on the number of Users recorded in a nominated
Area, i.e. Area automatically turns off when User count increments from 0 to
1. Area automatically turns on when User count decrements from 1 to 0.
57.10.3
Programming options shall provide for a User count “Trigger Level” to be
defined for any Area. When the trigger count is reached in an Area, a
nominated Auxiliary Output shall be switched on or off as required for the
purposes of disabling access to the Area. (i.e. When the number of Users in
the Area has reached the maximum number allowed such as in a Car Park).
The system shall also allow the Auxiliary Output to be returned to its normal
state when the User Count level drops below the trigger count.
57.10.4
An option shall be available to reset the User Count in a specified Area to 0.
Programming options shall provide for the Counter reset function to be
triggered manually by a User operation or Input (Keyswitch, etc.); or
automatically by a Time Program, Area status, or other operation as required.
57.10.5
The system shall allow installers to view and/or edit individual Area User
Count values when logged on to a User Terminal.
57.11
Location of Personnel
The system shall maintain a record of the current location (Area) of each User
in the system.
57.11.1
Authorised Users shall be able to view the current location of any User via a
Menu option when logged on to a User Terminal.
57.11.2
[Requires IN Readers and OUT Readers on every Door and methods
implemented to ensure every User always uses their card to access a door so
that multiple Users do not pass through any door on a single Users card
presentation]
57.12
Redundancy (Off-line Operation)
In the event of temporary loss of communications between the Control Module
and any Access Control Module, the following Door Access operations shall be
maintained with no degradation in performance or response times:-
57.12.1
Full access for up to 15 specified cards irrespective of Time or Alarm System
status on [List of Doors][firmware 3.55 or earlier].
AND/OR
57.12.2
Full access for up to 31 specified cards irrespective of Time or Alarm System
status on [List of Doors][firmware 3.56 or later].
AND/OR
57.12.3
Full access for up to 127 specified cards irrespective of Time or Alarm System
status on [List of Doors].[Special option. Only available on request]
AND/OR
57.12.4
Normal Door Access operations for all cardholders including permissions based
on Doors allowed, and where relevant, permissions based on Time Programs,
Mode of Access (i.e. Card and PIN and/or Dual User operation) and Extended
Access Times on [List of Doors].
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
115
57.12.5
During Off-line operation Door access operations may proceed without
reference to Alarm System status.
57.12.6
(Intelligent 4 Door Access Modules must be used)
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
116
58.
Lift Access Control
58.1
Lift Access Operations
The system shall be capable of providing Lift Access Control via any of the
following operations followed by selection of the Floor button required within
the button selection time.
(a)
Presentation of a Card (or other form of User ID token) at the Reader
assigned to the Lift Car.
(b)
Presentation of a Card at the Reader PLUS entry of a PIN code at the
User Terminal assigned to the Lift Car within a specified time period.
(c)
Presentation of a Card PLUS entry of a PIN code at a Proximity Reader
with built-in keypad assigned to the Lift within a specified time period.
(HID5355 and Motorola ARK-501 only)
(d)
Presentation of a Card PLUS entry of a PIN code at a 26 Bit Wiegand
Keypad wired in parallel with a 26 Bit Wiegand Proximity Reader (the
PIN code must be 5 digits in length and not greater than 65,536;
available with Single Door or 2-Door Access Module with V5.0 Firmware
or later only).
58.1.2
The User shall be restricted to selection of a single Floor for each Card
presentation and details of the Floor selected shall be logged to the Event
Review log.
58.1.3
[Available only if Lift Control with Button Feedback is utilised via Lift Interface
Boards or a high-level Lift Interface. Currently, high-level interfaces with OTIS
EMS – Security/BMS protocol and KONE HLI Security protocol have been
implemented.]
58.1.4
The mode of Access shall be programmed separately for each Lift in the
system. Options shall be provided to allow the mode of Access at any Lift to
be altered or cancelled according to a Time Program, Area Status (On, Off or
Alarm), Keyswitch Input or other mechanism as required.
58.1.5
The full range of Lift Access Control operations listed above shall be available
on all Lifts in the system regardless of the type of Reader Interface Module
installed.
58.1.6
Lift Floor “Free Access” and “Secure” operations shall also be available to
authorised Users via a Lift Control Menu when logged on to a User Terminal.
The User Terminal display shall provide text prompts for the User to specify
the Lift Car and Floor to control and the operation required.
58.2
Lift Access Timers
“Button selection time” shall be programmed separately for each Lift in the
system from 1 to 255 seconds in 1 second increments.
58.2.1
A programming option shall provide extended Button selection times for
disabled Users.
58.3
Review Log
Event Review Log entries shall be generated for every Lift Access operation.
Review log entries shall be time and date stamped with Month, Date and Time,
accurate to 1/10ths of a second resolution and shall identify the User, the
Mode of Access, the Lift controlled [and the Floor selected. (Available only if
Lift Control with Button Feedback is utilised via Lift Interface Boards or a Highlevel Lift Interface).]
58.4
Dual User Access
An option for Dual User access shall be able to be specified separately for any
Lift where the function is required.
58.4.1
The system shall provide the ability to define specific types of Users as “Dual
User Providers”, i.e. A User defined as a “Dual User Provider” must provide
the first User Card in Lifts defined as Dual User Access.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
117
NOTE: The system shall also have the ability to provide for any two Users to
gain access at Dual User Access Lifts by simply defining all types of Users as
“Dual User Providers”.
58.4.2
Dual User Access shall be compatible with Card access or Card & PIN access
operations.
58.5
Free Access - Enable and/or Disable
Programming options shall allow any individual Floor or any group of Floors in
a specified Lift Car or group of Lift Cars to be set to Free Access mode and/or
Re-secured via a Time Program, Input (e.g. Keyswitch), Area Status (On, Off
or Alarm), User Terminal operation, Logic Program or other mechanism as
required.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
118
59.
Plant Monitoring System
[NOTE: All Input processing features described in this application are
standard features that can also be utilised in the monitoring and processing of
any type of Zone Input in the system as required]
59.1
Partitioning
Provision shall be made for partitioning the system into separate Areas for
individual programming, monitoring and control. A minimum of 8 Areas shall
be available with options for up to 250 Areas per Control Module.
59.2
Area Control
Programming options shall allow for Area Off and On (Open / Close)
operations to be performed by Users, Inputs (e.g. Keyswitches), Time
Programs or Logic Programs and for Areas to be controlled either singly, or as
a group.
59.3
Siren Operation
The system shall provide the following Siren control options:
(a)
Two Siren Speaker Outputs for “External” and “Internal” Sirens shall be
provided on the Control Module and all Zone Expansion Modules
supporting 16 or more Inputs.
(b)
"Instant", "Delayed" and "Backup" Siren Modes shall be defined
separately for the External and Internal Siren Outputs in each individual
Area.
(c)
A minimum of 4 different Siren Tones shall be available that can be
defined separately for different types of Alarms. (e.g. "Bell", "Sweep",
"Fire" & "Evacuation")
(d)
Siren tones shall also be defined separately for Input Alarm and Input
Tamper conditions.
(e)
Open circuit on any dedicated Siren Speaker Output shall activate a
system alarm.
(f)
Two programming options shall be available for setting Siren Time: up
to 200 minutes in 1-minute increments or up to 55 seconds in 1-second
increments.
(g)
The "Backup" Siren Mode shall cause the Siren Speaker to sound only
when the backup communication task is triggered, i.e. there is a
primary communication failure.
(h)
An optional Holdoff Timer shall be provided for Siren Speaker Outputs,
to delay the sounding after an alarm is triggered. This timer shall be
programmable from 0 to 127 minutes in 1-minute intervals. This timer
will expire immediately by entering a valid PIN code to turn OFF the
Area the alarm is attached to while the Timer is still running.
59.4
Input Processing
The system shall provide for 16 already programmed default Input Processing
Types with options to support up to 64 different types.
59.4.1
Inputs may be assigned to more than one Area up to a maximum of 8 Areas.
59.4.2
Input processing shall be separately defined for each Area that an Input is
assigned to.
59.4.3
Input Alarm (Unseal) and Seal states shall be processed whenever an Area
that it is assigned to is On (Closed or Armed).
59.4.4
Input Tamper monitoring shall be maintained regardless of Area Status.
59.4.5
An Input processing option shall be available to “Latch” an alarm such that the
alarm message cannot be acknowledged by a User until the Input has
returned to the "Seal" condition.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
119
59.4.6
An Input processing option shall allow Pulse Counting to be specified for
individual Inputs where the nature of the Input device or the installation
environment require multiple “hits” to be recorded before registering an alarm
(Unseal) condition. The count number and pulse count time window shall be
programmable on a per Area basis.
59.4.7
An Input processing option shall allow delay in reporting an Input alarm with a
programmable timer from 1 to 255 seconds in 1-second increments.
59.4.8
An Input processing option shall allow an Input to cancel the running of an
Exit Delay Timer in an Area when the Input state changes from Seal to Alarm
(e.g. when a Push Button is pressed).
59.4.9
Input processing options shall allow the "Pin Type" for 8 Pin communication
format to be specified for individual Inputs with Verify Group logic when
applicable.
59.4.10
An Input processing option shall allow SMS alarm messages to be sent to one
or more telephone numbers with or without acknowledgement.
59.4.11
An Input processing option shall allow SIA alarm messages to be sent to one
or more Central Monitoring stations when an alarm condition takes place.
59.4.12
The following parameters shall be defined separately for each type of Input to
be processed:
(a)
Input States to be processed. These shall include Alarm (Unseal),
Tamper, Primary Entry Delay, Entry Delay (Hand-over), Exit Delay and
Pulse Count.
(b)
Input conditions to be reported. These shall include Alarm (un-seal),
Tamper, Isolated, Restore, Alarm during Entry Delay and Alarm during
Exit Delay.
(c)
Contact ID Event Code. (Standard default Event Codes shall apply if not
specified)
(d)
Area Auxiliary Outputs to activate.
(e)
Alarm Siren Tone and Tamper Siren Tone.
(f)
Siren Isolate (lockout) and Siren Re-trigger options.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
120
59.5
Defaults
A set of default Input processing options shall be available to simplify system
programming and shall provide for processing of the following basic Input
types:
Alarm Input Type
Example
Burglary Zone.
Internal PIR
Door Reed on Fire Door or Internal Door.
Door Reed on Entry Door.
PIR inside Entry Door.
Burglary Primary Entry/Exit Zone
Burglary Entry/Exit Zone. (Hand-over
Zone)
Local Silent.
(User Terminal message only)
Fire Zone.
Duress
Automation
System Tamper.
System Silent.
System LAN problems.
System Local.
Access Local.
Access Alarm.
Access Silent.
59.6
Smoke detector / Heat detector.
Keypad Duress alarm. (When a "Duress"
PIN Code is entered)
Duress or Silent Panic button.
Function Zone Inputs
Switches for control of lighting systems.
Cabinet Tamper / Siren Tamper.
AC Fail / Low Battery / Plant Alarms to
report.
Module Off-line.
Line fault / Comms fail / Local Plant
Alarms.
Too many PIN code attempts / Illegal
Card.
Door Forced.
Door Open Too Long.
Alarm Messages
Programming options shall allow the installer to define which types of alarm
messages are displayed on each LCD Terminal.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
121
60.
Event Counting
The system shall provide appropriate hardware and programming options to
allow up to 128 Event Counters to be managed by the system. Each Counter
shall provide 8-digit resolution and shall have a programmable text name of
up to 16 characters for easy identification.
60.1
Count Sensing
The Output from the device to be monitored shall be Normally Open dry
contacts and shall be connected directly to a Zone Input. An Open circuit to
Short circuit transition will cause the Counter to increment by a value of 1.
60.1.1
The system shall allow an up/down counting mode, in which case odd
numbered zones will cause the counter to increment and even numbered
zones will cause the counter to decrement.
60.1.2
Zone Inputs used for Event Counting shall not be limited to Inputs on the
Central Control Module.
60.2
Input De-bounce Time
Programming options for Event Counter Inputs shall allow the Input de-bounce
time to be programmed separately for each Input from 5 milliseconds to 1250
milliseconds (1.25 seconds).
60.2.1
(To provide the optimum de-bounce value for the required counter resolution
while still maintaining immunity to noise.)
60.3
Counter Integrity
The current count value shall be stored in non-volatile memory on the Module
that is utilised to monitor the device such that any disruption in LAN
communications will not compromise the accuracy of the Counter.
60.4
Trigger Counts
Programming options shall provide for one or two “Trigger Count values” to be
defined for each Event Counter.
60.4.1
When a trigger count is reached a pre-defined Input on the Module shall
change to the Alarm (Unseal) state. Separate Inputs shall be defined for each
of the two possible trigger count values.
60.4.2
The full range of Input processing options shall then be available to log the
event and activate any Messages, Outputs, Central Station Reports, etc. as
required.
60.5
Counter Reset
An option shall be available to reset any Event Counter to 0. Programming
options shall provide for the Counter Reset function to be triggered manually
by a User operation or Input (Keyswitch, Trigger Count, etc.); or automatically
by a Time Program, Area status, Auxiliary activation or other operation as
required. When a Counter is reset, the Inputs associated with the Counter
shall return to the Seal state.
60.6
View and Edit Counters
The system shall allow an option for authorised Users to view individual Area
User Counter and Event Counter values via a Menu option when logged on to a
User Terminal.
60.6.1
The system shall also allow an option for specially authorised Users to reset
and/or edit individual Area user Counter and Event Counter values via a
separate Menu option when logged on to a User Terminal.
60.6.2
When viewed on a User Terminal, the displayed Counter value shall refresh
every 2 seconds.
60.6.3
An option shall be provided for each Counter to limit the displayed Count value
to the 4 least significant digits.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
122
61.
Building Automation
61.1
Control of Outputs
Any Auxiliary Output in the system shall be capable of being controlled by any
one or more of the following:
(a)
Users via a User Terminal
(b)
Users via RF Fobs
(c)
Zone Inputs (Including Movement Detectors, Keyswitches, Button
Inputs, etc.)
(d)
Time Programs.
(e)
Area Status (On, Off or Alarm).
(f)
Auxiliary Logic Programs: Follow, Invert, AND, OR, XOR, NAND, NOR,
etc.
(g)
User Count value in an Area exceeding and/or dropping below
programmable pre-defined levels.
(h)
Event Counter value exceeding and/or dropping below programmable
pre-defined levels.
(i)
Analogue Input value exceeding and/or dropping below programmable
pre-defined levels.
(j)
Remotely via DTMF Touch-tone telephone, GSM Digital Mobile phone
and/or Computer.
(k)
HPM iControl outputs, groups or scenes.
(l)
Clipsal C-Bus Group commands.
61.1.2
Programming options shall allow any Auxiliary Output to have a timer
assigned that can be programmed to time for 1 to 254 seconds or 1 to 254
minutes. An option shall also be provided to generate a random timer
between 1 and 255 seconds or 1 and 255 minutes.
61.1.3
All Auxiliary Output actions shall be recorded in the Event log. A programming
option shall be provided for each Auxiliary Output to disable logging of Events
for that Output to preserve space in the Event log memory.
61.2
Control of Outputs by Users
The system shall provide the ability to control Auxiliary Outputs from specified
User Terminals and/or from a Host Computer if connected.
61.2.1
Selection of the Output to control shall be via programmable text names of up
to 16 characters and shall allow control of a single Output or a group of up to
8 Outputs.
61.2.2
Control options shall provide the ability to perform any of the following control
functions:
(a)
Output On.
(b)
Output Off.
(c)
Output Timed On for 1 to 255 seconds.
(d)
Output Timed On for 1 to 255 minutes.
61.2.3
The system shall provide a minimum of 8 User-controlled Outputs expandable
up to 128.
61.2.4
The following programming options shall be provided for each individual
Output to define the method of control via a User Terminal:
(a)
User Terminal Logon required - the User is required to logon to the User
Terminal with a PIN code and selects the Output to control via a Control
Menu.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
123
(b)
No Logon required - the User is provided with a list of Outputs to select
from via a single key press.
61.3
Control of Outputs by RF Fobs
The system shall provide the ability to control Auxiliary Outputs via up to 100
registered RF Fobs.
61.3.1
Control options shall provide the ability to perform any of the following control
functions:
(a)
Output On.
(b)
Output Off.
61.4
Control of Outputs by Inputs
The system shall provide the ability for specific changes of state on an Input
to control one or more Auxiliary Outputs.
61.4.1
Programming options shall provide the ability to define any of the following
control functions for an Input change of state. I.e. Seal and/or Alarm (Unseal) and/or Tamper (Open or Short circuit) states. The control function shall
be defined separately for each of the Input states as required:
61.4.2
(a)
Output On.
(b)
Output Off.
(c)
Output Timed On for 1 to 255 seconds.
(d)
Output Timed On for 1 to 255 minutes.
(e)
Output Toggled from current state to opposite state.
e.g.
(a)
A Momentary Push-button switch used for “Push on/Push off” operation
is programmed for “Toggle” on a change to “Alarm” state.
(b)
A Momentary Push-button switch or Movement detector used to activate
a light for 5 minutes is programmed to “Turn On for 5 minutes” on a
change to “Alarm” state.
(c)
A Two-position switch used for On/Off operation is programmed for “On”
on a change to “Alarm” state, AND “Off” on a change to “Seal” state.]
61.5
Control of Outputs by Time Programs
The system shall provide the ability for one Auxiliary Output or a group of up
to 8 Auxiliary Outputs to be controlled by a Time Program becoming Valid
and/or Invalid.
61.5.1
Programming options shall provide the ability to define any of the following
control functions for a Time Program going Valid and/or Invalid. The control
function shall be defined separately for the Valid and Invalid transitions as
required:
(a)
Output On.
(b)
Output Off.
(c)
Output Timed On for 1 to 255 seconds.
(d)
Output Timed On for 1 to 255 minutes.
61.6
Control of Outputs by Area Status
The system shall provide the ability for controlling one or more Auxiliary
Outputs according to specific conditions in an Area.
61.6.1
Programming options shall provide the ability to turn a specified Auxiliary
Output, or group of up to 8 Auxiliary Outputs, On and/or Off according to any
of the following Area conditions. A separate Auxiliary Output shall be able to
be defined for each condition and the control functions shall be defined
separately for each Area used in the system:
(a)
Area On and/or Off.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
124
(b)
Alarm in Area.
(c)
Tamper condition in Area.
(d)
Inputs Isolated in Area.
(e)
Siren running in Area.
(f)
Area Entry Timer running.
(g)
Area Exit Timer running.
(h)
Area Defer Timer running (250 seconds before the Timer expires)
(i)
Area in Pre-Arm Walk Test mode.
61.7
Control of Outputs by Auxiliary Logic Programs
The system shall provide the ability to program simple Logic equations
utilising one or two Auxiliary Outputs.
61.7.1
The Logic equation “result” shall have the ability to:
(a)
Control one or more Auxiliary Outputs.
(b)
Generate an Alarm (Unseal) and/or Seal state on a specified Zone
Input.
(c)
Control Door or Lift access.
(d)
Control Areas.
61.7.2
The system shall provide a minimum of 16 Logic Programs expandable up to
128.
61.7.3
Programming options shall provide the ability to perform the following Logic
functions as a minimum utilising one or more Logic Programs:
(a)
Result to follow or invert a single specified Auxiliary Output.
(b)
Result to turn On and/or Off when a single specified Auxiliary Output
turns On and/or Off.
(c)
Result to turn On for a time period of 1 to 255 seconds or 1 to 255
minutes when a single specified Auxiliary Output turns On or Off.
(d)
AND, OR, XOR (Exclusive OR), NAND and NOR functions.
(e)
Result to Unlock and/or Lock Doors when a single specified Auxiliary
Output turns On and/or Off.
(f)
Result to Free and/or Secure Lift Floors when a single specified Auxiliary
Output turns On and/or Off.
(g)
Result to turn Areas On and/or Off when a single specified Auxiliary
Output turns On and/or Off.
61.8
Remote Control of Outputs
Remote controlled Outputs shall also be able to be controlled by DTMF Touchtone Telephones, GSM Mobile Phones, Computers or other mechanism as
required.
61.8.1
DTMF TOUCH-TONE REMOTE CONTROL
The system shall provide the ability to control Auxiliary Outputs from any
Touch-tone (DTMF) telephone. The system shall provide a minimum of 4 DTMF
controlled Outputs expandable up to 16.
61.8.2
Dialling the system and sending a single programmable DTMF tone shall
access DTMF Control. Once connected to the system, the system shall send a
“Start tone” to indicate the Ready state. Selection of the Output to control
shall then be via programmable 4 digit Control codes.
61.8.3
The command timer shall timeout and disconnects if more than 10 seconds
elapses before entering the first digit of the Control code or between entering
each subsequent digit of the Control code.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
125
61.8.4
The system shall disconnect if a valid Control code is not entered after 6
successive tries.
61.8.5
Control options shall provide the ability to perform any of the following control
functions:
61.8.6
(a)
Output On.
(b)
Output Off.
(c)
Output Timed On for 1 to 255 seconds.
(d)
Output Timed On for 1 to 255 minutes.
The system shall provide User feedback via distinct DTMF tones to indicate any
of the following conditions:
(a)
Start (Ready) tone.
(b)
Output turned On (Or already On).
(c)
Output turned Off (Or already Off).
(d)
Error - to indicate Code not recognised, Operation cannot be executed
or Timeout.
61.8.7
GSM DIGITAL MOBILE REMOTE CONTROL
The system shall provide the ability to control Auxiliary Outputs from any GSM
Digital Mobile telephone with Short Message Service (SMS) enabled. The
system shall provide a minimum of 8 GSM controlled Outputs expandable up
to 128.
61.8.8
Selection of the Output to control shall be via pre-defined, simple, userfriendly text messages and shall allow control of a single Output or a group of
up to 8 Outputs.
61.8.9
Control message options shall provide the ability to perform any of the
following control functions:
61.8.10
(a)
Output On.
(b)
Output Off.
(c)
Output Timed On for 1 to 255 seconds.
(d)
Output Timed On for 1 to 255 minutes.
(e)
Return list of text names and current status of 5 sequential Outputs.
The following programming options shall be provided to define GSM Mobile
phone access to the system:
(a)
Specified GSM Mobile phones only. Access will be limited to one or two
GSM Mobile phones by programming the phone numbers into the
system.
(b)
Any GSM Mobile phone. Access allowed to any GSM Mobile phone but
the User must prefix the Control message with a valid PIN code.
61.8.11
The system shall return a text message to the GSM Mobile phone that
indicates the result of any Control message sent.
61.9
Status Monitoring and Control via simple Automation Interface
The system shall provide (as an option) an RS232 Serial interface for
connection to Third Party Home Automation and Building Automation Systems.
The protocol to be used will be an ASCII based protocol for ease of
understanding.
61.9.1
The simple Automation interface will provide the following functions:
(a)
Request state of Zone Inputs, System Inputs, Areas, Doors, Auxiliaries
and Home Auxiliaries.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
126
(b)
Request text names for all named entities. (e.g. Areas, Inputs, Users,
Doors, Home Auxiliaries, Time Zones, etc.)
(c)
Control Area, Door, Auxiliary and Home Auxiliary states.
(d)
Isolate/De-isolate Zone Inputs and System Inputs.
(e)
Manipulate Control Module Zone Input states.
(f)
Access the Review log. (Includes options for streaming,
acknowledgement and pointer manipulation)
61.9.2
The system shall provide an option for monitoring communications integrity on
the interface.
61.10
Control of Outputs by Clipsal C-Bus
The system shall provide the ability to control Auxiliary outputs via Clipsal CBus Group commands.
61.10.1
An Auxiliary linked to a C-Bus Group Address shall have an option to allow the
Auxiliary to:
(a)
Turn on when an ON command is detected
(b)
Turn off when an OFF command is detected
(c)
Turn on above a pre-programmed ramp level threshold and off below
that threshold
61.11
Control of Outputs by HPM iControl
The system shall provide the ability to control Auxiliary Outputs via HPM
iControl channels, groups and scenes.
61.11.1
For iControl auxiliaries programmed for “scene” commands, the Auxiliary will
turn on when the scene turns on, and off when the scene turns off.
61.11.2
For iControl auxiliaries programmed for “channel” or “group” commands, the
Auxiliary will turn on above a programmed threshold (between 0% and 100%)
and off below that threshold.
61.12
Building Automation Systems
61.12.1
The system shall natively allow interaction with many 3rd party building
automation systems.
61.12.2
The system shall allow, via the addition of a Trans-Tech hardware or software
module, interaction with all major building automation and HVAC
communication protocols including:
360 Vision Technologies' Dome and Controls
CCTV system
ABB ACS 500 (SAMI GS) frequency
converters
ABB ACS 600 variable speed drives
ABB DCS variable speed drives
Access single door control
AD Network Video NetVu Video Desktop
CCTV system
Adam Systems Alarm Receiver System
Ademco Microtech Galaxy Security System
Ademco/Honeywell Video Systems
VideoBlox matrix switchers
Advance Power Systems PC1200 Rectifiers
Advantech ADAM 4000 Series
Aertesi MaxiNet BMS
Agritron MegaPoint sensor monitoring
system
Alerton LSI BMS
Alfa Laval Automation SattCon
Alldales Drive Systems Gemini GV
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
127
frequency converters
ALSTOM GEM80 series PLC
American Auto-Matrix SAGE controller
American Auto-Matrix Unitary Controllers
Andel Floodline 128 Leak Detection System
Andover Controls Infinity/Continuum
Systems
Andover Controls Nucleus/AC8+/AC257
APC Silcon UPS
APC Smart and Matrix UPS
ASI Controls VAV
Asutsa TLVCR964 Video Cassette Recorder
Autoflame DTI boiler/burner controls
Automated Logic controls
Autometers EVO IC Series Harmonic
Analyser meters
Autometers IC Series power meters
BACnet open protocol
Baxall Security's ZMX+ Series Multiplexers
Belimo Automation MP-Bus Actuators
Benning Power Electronics MCU 1000/2001
Betatech Master Series matrix switchers
Bosch DP6000 paging system
Building Block Video Tx1000 System
Canatal International Precision Air
Conditioning system
Carel air-conditioning and refrigeration
controllers
Carlo Gavazzi WM3-96 Smart Quality Power
Analyzer
Carrier CCN DataPort I Systems
Carrier CCN DataPort II Systems
Caterpillar generator
Cerberus/Siemens AlgoRex Fire Panels
Cerberus/Siemens CS11 Security Panels
Cerberus/Siemens CS1115 Fire Panels
Colt International OPV Control system
COMLI protocol
Complus Teltronic GE 100 Intercom
Computar DPLEX 9/16 Video Multiplexer
Cooper Menvier/JSB Electrical Easicheck
Emergency Lighting System
Cooper Menvier/Scantronic Security System
Cover Partner UPS
Crestron Home Automation
Crompton Integra 2000 power meter
Cylon Controls Unitron Range
Daikin DBACS Air Conditioning
Daikin VRV Controls
Danfoss Refrigeration controls
Danfoss VLT 3500 Frequency Converters
Danfoss VLT 6000 Frequency Converters
Dedicated Micros DVST Video Transmission
System
Dedicated Micros Sprite Video Multiplexers
Dedicated Micros Uniplex Series 2 Video
Multiplexer
Deep Sea Electronics 55x Generator Monitor
Deltec Power Systems UPS
Denco Millennium Access Module
Denco Monitrol system
Denco Monitrol system via a CIU
Dorman-Smith Load Module 3-phase energy
analyser
Duemmegi Conatto IO system
Dunham Bush Chiller controls
ECS Philips LightMaster System
Elcontrol Energy Net VIP Energy/VIP One
meters
Electronic Security Products CS16 Spider
Elgama LZQM/LZMF Electricity Meters
Eltek PRS Power Rectification System
Enercom EMA
Enercom IsoBase/IsoHub Earth Leakage
Monitoring
Enercom Isobox Earth Leakage Monitoring
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
128
Esser/Novar System 8000 Series Fire Panels
European Installation Bus (EIB) network
European Selective Paging Association
(ESPA) 4.4.4 protocol
Europlex Technologies Aplex/Midiplex/3GS
Intruder Systems
Exide Electronics UPS
Exide Electronics UPS with BCM protocol
Exide Electronics UPS with P-Record
protocol
Fermax Digital Entry Phone System
Fermax MDS Door Entry System
FG Wilson generators
Fiskars Power Systems UPS
Fronius IG photovoltaic system
Gent/Novar 3400/Vigilon Fire Panels
Gent/Novar 8000 Series Fire Panels
Geoquip Electronic Perimeter Detection
System
Hitachi CS-Net Air Conditioning
Hitzinger Powercon System
Hochiki ESP Fire Detection panels
Honeywell Excel 5000 System
Honeywell Q7700 Boiler/Burner Control
system
Honeywell XLS50/60 Fire Panel
Honeywell XLS80 Fire Panel
iLight iCan lighting control system
iLight/Dynalite DyNet lighting control
network
IME Nemo 96 Power Measurement unit
Innsite Hotel Services Energy Management
System
Invertomatic Telecontrol UPS system
JBus protocol
JBus protocol (slave)
Johnson Controls Metasys system
JVC BR-S925E Video Cassette Recorder
Kamstrup Electricity meters
Kamstrup Multical heat meters
Key Universal Building Systems Apex
Display
Kidde Fire Protection GRS network
Kidde Fire Protection MARS network
Kidde Fire Protection Vega or Procyon Panel
Kohler Power Systems Decision-Maker
generator
Landis & Staefa/Siemens AS1000 BMS
Landis & Staefa/Siemens IS1000 Display
Landis & Staefa/Siemens MS2000
NCRS/NCRE System
Landis & Staefa/Siemens NCRE Trunk Bus
Landis & Staefa/Siemens Pronto BMS
Landis & Staefa/Siemens Visoni PRV2
controller
Liebert Datawave PDU
Liebert DCLAN Interface
Liebert ECA2 Environmental
Communications Adapter
Liebert Hiross Air Conditioning
LonWorks networks via Echelon Serial
LonTalk Adapter
Luxmate building management system
Mark Mercer Electronics PTZ Dome cameras
McQuay International's Chiller System
Controller (CSC)
McQuay International's Frame 4 Chillers
McQuay International's range of Air-Cooled
(Stargate) Screw Chillers
McQuay International's range of Centrifugal
Chillers
McQuay International's range of
Reciprocating Chillers
McQuay International's range of Roof-Top
Units
McQuay International's range of Unit
Ventilator
McQuay International's Self-Contained Air
McQuay International's Series 200 Flooded
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
129
Conditioning Units
Screw Chiller
McQuay International's Water Source Heat
Pump
Meaco Radio Telemery System
Megacon AB ISORACK 2000 Earth Leakage
Condition Monitoring System
MegaTec compatible Advance-Intelligent
UPS
Meissner MP100 Series UPS
Meissner MP3000 Sentinel Series UPS
Meitav MaxiNet thermostat network
MEM Memshield Circuit Breaker Protection
System
Menvier TS2500 Intruder Alarm Control
System
Merlin Gerin Galaxy PW UPS
Microlec SmokeMaster system
Minerva Fire Panel
Mitsubishi Electric City Multi air conditioning
system (via IFU-100SA)
Mitsubishi Electric City Multi air conditioning
system (via IPxxM)
Mitsubishi Electric Mr Slim air conditioning
system (via IPxxM)
Mitsubishi HS-S5600 Series and HS-S8300
Series Video Cassette Recorder
Modbus protocol
Modbus protocol (slave)
Molynx Visilynx CCTV system
Morley-IAS Fire Systems (multiple ZX
panels)
Morley-IAS Fire Systems (single ZX series
panel)
Multitone Access 3000 paging system
Newport Data Systems Cellwatch 2 software
North Building Technologies Commander
North Communications ObSys Display
North Compass Network Link via Modem
North Compass Open Link (COL) protocol
North Compass Simple Gateway protocol
North ObSys PC Information
North Simple Terminal Object protocol
North XOM ActiveX Control
North XOM Alarm Archive
North XOM Alarm Dispatch
North XOM Alarm Email/SMTP Gateway
North XOM Alarm Generator
North XOM Alarm History
North XOM Alarm Printer
North XOM Alarm Printer (serial)
North XOM Alarm Priority Translator
North XOM Alarm Router
North XOM Alarm Store
North XOM Alarm to Object
North XOM Alarm Translator
North XOM Calendar Timer Control
North XOM Data Log Archive
North XOM Data Logger
North XOM IPBus protocol
North XOM Meter Logger
North XOM Programmable Control
North XOM Shared Token Database
North XOM SMS Portal
North XOM SNMP Trap Portal
North XOM Transfer Interface
North XOM User Data
North XOM User Locator Database
North XOM Web Server
North Zip System
Northern Design PM390 power meter
Notifier Fire Systems
Omron Programmable Logic Controllers
(PLC)
PABX Systems with CDR output
PABX Systems with DTMF input
PAC International 2100 series door
controller
Pelco CM9760 Series Video Matrix
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
130
Peripheral Support Services FireQuest Fire
Detection panels
Philips DP6000 paging system
Philips Helio Lighting Control System
PHP compatible products
Power Measurement 3300 ACM power
monitor
Power Measurement 7300 Ion power
monitor
Power-One DC Power Systems
Powerware Corporation UPS with BCM
protocol
Powerware Corporation UPS with P-Record
protocol
Protec Fire Detection control panels
PUP compatible products
RF Solutions Radio Modems
Rhoss Fan Coil Units
Sabroe's Unisab and Prosab II refrigerating
compressors
Sanyo AMY air conditioning system
Satchwell Satchnet protocol
Schneider Digipact PM300 power meter
SDA Protec SMS 5000 alarm monitoring
system
SeaChange hvac control systems
Serial Alarm Messages
Siebe I/A MicroNet VAV Controls
Siemens Desigo PX controls
Siemens SED2 Variable Frequency Drives
SimplexGrinnell Simplex 4100 series fire
alarm system
SmartKontrols hvac control systems
Socomec Diris Ap power meter
Socomec Sicon Delphys UPS
SocoMec UPS
Staefa Smart I controllers
Starkstrom Circutor power meters
Static Systems Series 900 fire alarm system
Stulz CompTrol Air Conditioning via MIB
Systems Controls & Instruments (SCI)
MaxiNet thermostat network
TAC UniHub Display
TAC Xenta HVAC Controllers
TAC/CSI I/NET
Tecton's Darlex 20 Digital Video Recorder
Tek-Air MPC-2000 Gateway
Telocator Alphanumeric Protocol (TAP)
Texcel Technology Vision VE5000 system
Thorn Security Infinity BMS
Thorn Security Star bms
Titus ASIC VAV control system
Titus ZCom VAV zone control
TraceTek SIM/TTDM Leak Detection
Trane GCI chiller controls
Trane Tracer Summit controls
Trend Control Systems IQ Series BMS
Trend Control Systems IQ Time Zone
expansion module
Trend MP/MPO power meter
Triatek Lighting control system
Tyrrell Systems CrossTalk Display
Ultrak/Honeywell Video Systems MAX-1000
video management system
Uniflair Air-conditioning controllers
Uninterruptible Power Supplies PowerWAVE
UPS
Veeder-Root TLS series tank-monitoring
system
Vicon AurorA digital video multiplexer
Vicon NOVA and 1300 CPU matrix systems
Vision Systems Adpro Fast Scan Series III
Vision Systems Adpro VST-10 Fast Scan
Series
Vision Systems VESDA aspirating smoke
detection system
Viterra Combimeter II heat meter
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
131
WattMaster Controls Auto-Zone system
York FM Display
York International ASCII Microgateway
York International ISN Controls
York International YorkTalk Controllers
Ziton ZP fire detection systems
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
132
62.
Zoned Air-conditioning Control
The system shall provide dedicated Air-conditioning Control logic for the
control of up to 4 Air-conditioning units. Each unit shall consist of a single
compressor and monitoring and control of up to 8 Air-conditioning Zones.
62.1
Control
Control of the Air-conditioning unit/s shall be through either or both of the
following options:
(a)
Automatic via Thermostats and/or Time Programs and/or Area On/Off
status.
(b)
Manual via separate 3-position switches for:
1.
System ON / OFF / TIMEZONE CONTROL
2.
Ventilation RECIRC / FRESH / AUTO
3.
Fan ON / HEAT PUMP / AUTO
OR
Manual via User Terminals.
62.2
62.3
Inputs
For each Air-conditioning unit the system shall be able to provide:
(a)
Up to 8 Thermostats connected to separate sequential Inputs with Endof-line resistors to monitor “Too warm”, “Dead band” and “Too cool”
conditions in each of the 8 possible Zones.
(b)
A single Thermostat connected to an Input with End-of-line resistors to
monitor the external air “Too warm”, “Dead band” and “Too cool”
conditions. [If required for automatic Fresh/Re-circulated air selection.]
(c)
Three 3-position switches connected to 3 sequential Inputs with End-ofline resistors for control functions. [If User Terminal control not used.]
Outputs
For each Air-conditioning unit the system shall be able to provide:
(a)
Up to 8 sequential Relays to control the Zone Damper for the outlet in
each of the 8 possible Zones.
(b)
Up to 8 sequential Relays to control the following functions as required:
1.
Compressor On/Off.
2.
Compressor Heat/Cool.
3.
Re-circulated/Fresh Air Damper.
4.
Fan On/Auto.
5.
Compressor Bypass Damper Open/Close.
6.
Exhaust Re-circulated air Damper Open/Close.
7.
Disable. (Special control auxiliary manipulated by other
tasks)
8.
Smoke Mode. (Special control auxiliary manipulated by other
tasks)
62.4
Minimum On Time / Off Time
The system shall allow the minimum Compressor On time and Off time to be
specified for each Air-conditioning unit.
62.5
Bypass Damper
The system shall allow the installer to specify the number of Zone Dampers
that must be open to allow the Compressor Bypass Damper to be closed.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
133
63.
System Diagnostics
63.1
Inputs
The system shall allow the Installer to view the current status of any Zone
Input in the system via a Menu option when logged on to a User Terminal.
63.1.1
The system shall allow the Installer and any other authorised Users to Isolate
and De-isolate any Zone Input in the system via a Menu option when logged
on to a User Terminal or via a local or remote PC.
63.2
Outputs and Sirens
The system shall allow the Installer to view the current status of any Auxiliary
Output in the system and turn any Auxiliary Output On or Off via a Menu
option when logged on to a User Terminal or via a local or remote PC.
63.2.1
The system shall allow the Installer to view the current status of any Siren
Output in the system and turn any Siren Output On or Off via a Menu option
when logged on to a User Terminal.
63.3
PSTN Dialler Line
The system shall allow the Installer to perform the following operations on the
PSTN Dialler circuit via a Menu option when logged on to a User Terminal.
(a)
View the current line status. Line present / No line / Line Seized / Line
Un-seized.
(b)
Toggle the “Seize” relay On and Off.
(c)
Loop and Un-loop the Line.
(d)
Select between DTMF and Decadic (Pulse) dialling.
(e)
Dial a telephone number using the digit keys on the User Terminal.
63.4
Cards
The system shall allow the Installer to view the raw data from any card format
supported by the system or any Wiegand card regardless of format, via a
Menu option when logged on to a User Terminal.
63.5
Memory
The system shall allow the Installer to run a memory check to determine the
time and date of the last change to any specific database via a Menu option
when logged on to a User Terminal.
63.6
RS232 Serial Ports
The system shall allow the Installer to perform the following operations on any
Serial Ports installed on the Control Module via a Menu option when logged on
to a User Terminal.
63.7
(a)
View the current status of the relevant IN signals. DCD (Data Carrier
Detect) / CTS (Clear to Send) / DSR (Data Set Ready) / RI (Ring
Indicator).
(b)
View the current status of the relevant OUT signals. DTR (Data
Terminal Ready) / RTS (Request To Send).
(c)
Toggle the DTR or RTS signal High and Low.
Module Power Supplies
The system shall allow the Installer to monitor the status of the following
conditions on the relevant Modules via a Menu option when logged on to a
User Terminal.
(a)
LAN fail.
(b)
AC fail.
(c)
Low Battery or Low DC Volts.
(d)
Detector fuse fail and LAN fuse fail.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
134
63.7.2
63.8
The system shall allow the Installer to perform the following power supply
tests on any Module via a Menu option when logged on to a User Terminal.
(a)
Turn Zone Expansion Module battery chargers On and Off.
(b)
Turn the Control Module battery charger On and Off.
(c)
Unlock and Re-lock all Doors.
Module Disable
The system shall allow the installer to disable one or more modules on the
LAN. Disabling a module will cause the Module to stop attempting to
communicate with the Control Module and will also cause all Zones and
System Inputs on that Module to be Sticky Isolated.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
135
(This page has been intentionally left blank)
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
136
Appendix A - Core
Requirements
64.
Software
64.1
Encryption
64.1.1
Communications between Server and Clients will be encrypted with a
minimum of 128-bit encryption (e.g. Blowfish 128-bit)
64.1.2
Communications between the Server and Control Modules shall be encrypted
with a minimum of 128-bit encryption (e.g. AES 128-bit)
64.2
Virtual Panel
64.3
The software will allow multiple panels to be grouped together into a single
virtual panel. Cardholders can be programmed in one place, and changes will
automatically be sent to each member panel.
64.4
Universal Tenanting
The system will permit any item to be assigned to tenants. This includes
areas, doors, cardholders, auxiliaries, zones, modules and all other
programming items; and also front-end entities like floor-plans, sites and
workstations.
64.4.1
When an Operator logs on, their tenant list will be loaded by the system and
used as a filter to determine what items the Operator can or cannot see.
64.4.2
Items that aren’t tenanted will be visible to ALL Operators.
64.4.3
Items can be placed in more than one tenancy.
64.4.4
An Operator can see an item if they share a tenancy in common with that
item.
64.5
Cross-Reference
The software shall allow Operators to view relationships between all Control
Module programming items. The software will display a ‘tree’, showing how
any item (e.g. user, door, area) relates to all other items.
64.6
Detect Two Operators Editing The Same Data
The system shall warn an Operator who simultaneously edits the same record
as another Operator. The system shall prompt the Operator whether to discard
or override the other Operators edits (subject to Operator permissions).
64.7
Workstation Lockdown
The system shall be configurable to only permit client logons from designated
workstations.
64.8
Push Programming
The system shall send programming changes through to field hardware
without any special LAN commands such as LAN Init or LAN Secure. Field
hardware will adopt the new programming immediately and automatically.
64.9
Monitoring Field Programming Changes
The system shall automatically detect if any system parameters have been
changed at a terminal. The system will notify the Operator which item(s) were
changed. The Operator can choose to accept or reject the changes.
64.10
Software Video Multiplexing
The system will allow up to 16 cameras to be multiplexed onto a single, timesynchronised window. The layout can be changed at any time. Any number of
separate multiplexed windows can be displayed, with each showing footage
from the same or different cameras and DVRs.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
137
64.11
Shaped Areas On Floor Plans
The system will let Operators create areas of any shape. The following shapes
are examples of shapes that must be definable:
64.12
Report Designer
The system will include a fully featured WYSIWIG (what you see is what you
get) report designer that can edit existing report templates or create brand
new templates. The report designer will allow operators to:
64.13
(a)
Place coloured and formatted text and graphics on a report
(b)
Place data fields onto a report, including user photographs
(c)
Add drawing shapes and symbols
(d)
Place charts on a report based on live reporting data
(e)
Add barcodes to a report
(f)
Place tables on a report of tabular data grouped by arbitrary datum
(g)
Add forms to a report
(h)
Place runtime data from other applications using industry-standard OLE
container objects
Operator Permissions
Permissions can be applied to specific items. For example, an operator might
have the ‘see’, ‘inspect’ and ‘change’ permissions for doors 1-5 and 20, but
only the ‘see’ and ‘inspect’ permission on all other doors.
(a)
See. Without this permission, the item is invisible to the Operator.
(b)
Inspect. Without this permission, the Operator cannot open the item
for inspection.
(c)
Change. Without this permission, the Operator cannot save changes to
the item.
(d)
Create. Without this permission, the Operator cannot create new
instances of the item.
(e)
Delete. Without this permission, the Operator cannot delete the item.
(f)
Control (field hardware only). Without this permission, the Operator
cannot control the field hardware item.
(g)
Print. Without this permission, the Operator cannot print the item.
(h)
Export. Without this permission, the Operator cannot export the item to
a file.
(i)
Set Permissions. Without this permission, the Operator cannot modify
the permissions of the item for themselves or other Operators.
64.14
Compliance
The front-end software will be written in Microsoft Visual C++ and built using
Microsoft compiler tools.
64.14.1
The front-end software will comply with Microsoft’s User Interface Guidelines.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
138
65.
Hardware
65.1
Field Hardware Independence
If the front-end software is not running, the field hardware will continue to
function at full capacity, including authentication of all users.
65.2
Field Hardware Programming
The system shall permit ANY programmable item to be programmed in the
field from a System Terminal, without recourse to a computer of any kind.
65.3
TCP/IP Network Independence
The system shall support the option to deploy on non-TCP/IP networks. If a
TCP/IP network goes down, the system shall have a private non-TCP LAN
which will continue to function.
65.4
Automatic Link Switching
The system can be configured to automatically try different links if the primary
link fails. For example, if the TCP/IP connection is disconnected, the system
will connect on a dial-up link or backup serial link. When the primary link
returns, this will be detected and reconnected automatically.
65.5
Alarm Prioritisation
The Control Module will transmit alarm events in priority to regular review
events.
65.6
Multi-Purpose Detectors
The system shall permit a single detector to be used for up to 8 different
purposes. (e.g. add a single detector to two different areas with two different
process groups.)
65.7
Alarm Reporting
The system shall be capable of reporting different alarm types via different
communication paths to different locations.
66.
Functional
66.1
Alarm Routing
The system shall have the capacity to report alarm events of different types or
from different origins via different communications formats to different
locations.
66.1.1
For example:
66.1.2
(a)
Security alarms from one section or tenant go to ABC Control Room Ltd.
via dialler.
(b)
Security alarms from another section or tenant go to XYZ Alarm
Monitoring Ltd. via dialler or GSM modem.
(c)
All building plant alarms go to an engineer via an SMS message.
The system shall allow the same alarm to be processed by up to ten
communication tasks, with each task able to report in a different format to a
different location.
© 2007 Inner Range Pty. Ltd.
Rev. 7.6 (v4.2.1/v7.6)
March 2010
139