<SpecificationName>

1. Functional Overview

1.1. The ISMS shall allow multi-site configuration and be able to be managed by one or
more of the connected sites.

1.2. The ISMS shall include in the core product code (but not be limited to) the following:

1.2.1. access control,

1.2.2. alarms management,

1.2.3. cardholder management,

1.2.4. CCTV integration,

1.2.5. visitor management,

1.2.6. guard tour,

1.2.7. perimeter deterrent and detection.

1.3. The ISMS shall provide a means to control access through nominated doors having
electric locking door status monitoring and token or biometric access control readers.
Access rights associated with a presented access token or biometric identifier shall be
checked for validity based on token or identifier, access area, access time and any
other access management function defined in this specification. All validity criteria
shall be stored at the IFC. Access shall be granted or denied dependant on the access
privilege. Access rights shall be programmed in a variety of ways to allow flexibility as
defined elsewhere in this specification.

1.4. The ISMS shall provide access control in elevators enabling access to any combination
of floors over specified time periods. The interface to the elevator manufacturers
equipment shall be by either low level interface (relay outputs) or by a high level (data)
interface.

1.5. The ISMS shall monitor the condition of inputs. The ISMS shall be able to be
programmed to apply a variety of conditions to the way in which these inputs are
monitored and shall enunciate the condition of such inputs in accordance with such
programming.

1.6. The ISMS shall provide a fully functional intruder alarm system including entry and exit
delays where intruder detection sensors are connected to system inputs. The intruder
alarm ISMS component shall be fully integrated with the access control aspects of the
system. It shall be possible to set (secure) or unset (unsecure) areas from any access
control reader associated with an area, access control reader with keypad, AMT, or as
required from defined central control locations.

<SpecDate> Page 1
 <SpecificationName>

1.7. The ISMS shall provide an integrated software facility for the design and production of
photo ID cards.

1.8. Connection between ISMS servers and IFCs shall be achieved using cabling supporting
the TCP/IP protocol. The network connection must be on-board the IFC. Interface
transceiver units (Ethernet to RS485, RS232 etc) are not acceptable.

1.9. The ISMS shall have IPv6 address support for all TCP/IP network devices.

1.10. Remote IFCs not permanently connected to the network can be connected via a PSTN
service, using TCP/IP protocols.

1.11. Connection from a remote IFC to the server shall be either via dialup to an Internet
Service Provider (ISP) using encrypted TCP/IP, and then via an approved firewall
through into the IT environment or via dialup directly to a RAS connection on the
Server.

1.12. All system software upgrades shall be transmissible through the network to the IFC,
readers, and I/O devices.

1.13. IFCs must support peer to peer communications for input and output communications
between IFCs. Systems that require a server for communications between panels are
unacceptable.

1.14. All data communication between the ISMS and IFCs shall use an industry standard
asymmetric encryption algorithm for mutual authentication and session key
negotiation. This algorithm shall be equivalent to ECC P-384 or stronger. Session keys
shall be re-negotiated on a regular basis at intervals no longer than 30 hours.

1.15. All data communication between the ISMS and IFCs shall be encrypted using an
industry standard symmetric encryption algorithm equivalent to AES-256 or stronger.

1.16. All data communication between IFCs shall use an industry standard asymmetric
encryption algorithm for mutual authentication and session key negotiation. This
algorithm shall be equivalent to ECC P-384 or stronger. Session keys shall be re-
negotiated on a regular basis at intervals no longer than 30 hours.

1.17. All data communication between IFCs shall be encrypted using an industry standard
symmetric encryption algorithm equivalent to AES-256 or stronger.

1.18. All data communication between IFCs and intelligent edge devices such as readers and
I/O devices shall use an industry standard asymmetric encryption algorithm for mutual
authentication and session key negotiation. This algorithm shall be equivalent to ECC
P-256 or stronger. Session keys shall be re-negotiated on a regular basis at intervals no
longer than 30 hours.

1.19. All data communication between IFCs and intelligent edge devices such as readers and
I/O modules shall be encrypted using an industry standard symmetric encryption
algorithm equivalent to AES-128 or stronger.

<SpecDate> Page 2
 <SpecificationName>

1.20. All dry contact type input to field I/O modules must support four state monitoring with
the ability to configure the resistance values of the state changes.

1.21. The ISMS shall report all events to the operator(s) as configured and shall produce and
maintain a log of all system events, alarms, and operator actions.

1.22. The ISMS shall provide a means for an operator to extract information relative to the
event log and system configuration and produce this information in the form of
printed reports, emailed reports directly from the ISMS itself, screen displays, or
exported files.

1.23. The ISMS shall provide for a GUI with site plans and interactive icons representing the
location and real-time status of all monitored hardware within the ISMS.

1.24. The ISMS shall provide emergency evacuation reporting.

1.25. The ISMS shall be designed and manufactured by a company who shall be certified
under the ISO 9001:2008 (or later) quality procedures.

1.26. Where applicable, equipment shall have the following approvals:

1.26.1. FCC Part 15

1.26.2. CE approval BS EN 50130-4 Alarm Systems Electromagnetic Compatibility

(Immunity)

1.26.3. CE approval BS EN 55022 Emissions

1.26.4. UL294 Access control

1.26.5. UL1076 Burglar Alarms

1.26.6. ULC-ORD-C1076

1.27. Encoders and readers shall also meet:

1.27.1. CE ETS 300 683 Short Range Devices

1.27.2. C-Tick AS/NZS 4251 Generic Emission Standard

1.27.3. C-Tick RFS29

1.28. The ISMS software shall be written in a fully structured, fully validated, and
commercially available language that provides a strictly controlled development
environment.

1.29. The user interface for operational management of site security shall be developed
using Microsoft .NET and Windows Presentation Foundation (WPF) development tools.

1.30. Comprehensive backup and archiving facilities shall be incorporated as an integral part
of the ISMS.

<SpecDate> Page 3
 <SpecificationName>

1.31. The ISMS shall include partitioning suitable for multi-tenanted buildings. operators
shall only be able to access those parts of the system which fall within their division
and operator privileges.

2. Video Management System Integration

2.1. The ISMS shall be capable of concurrently interfacing with VMS from multiple vendors.

2.2. It shall be possible for the ISMS to view live video from multiple cameras within its
interface.

2.3. The ISMS shall be capable of viewing stored (archived) video from the VMS within its
interface.

2.4. Where supported by the integrated VMS, it shall be possible to operate camera
controls such as:

2.4.1. PTZ,

2.4.2. pause,

2.4.3. forward,

2.4.4. rewind.

2.5. It shall be possible to maximise a camera window.

2.5.1. Whilst a camera window is maximised, the other camera windows should be
changed to live thumbnail images to ensure the operator is able to see
activity in all cameras.

2.6. It shall be possible to drag a camera icon from a site plan into a video view to
dynamically be able to view cameras in an ad hoc manner.

2.7. It shall be possible to drag a camera icon from a list into a video view to dynamically be
able to view cameras in an ad hoc manner.

2.8. It shall be possible to find a camera from a search box.

2.9. Where supported by the integrated VMS, it shall be possible for the ISMS to send a
message to the VMS to move cameras to priests.

2.10. Where supported by the integrated VMS, it shall be possible for the ISMS to receive
motion detection and video analytic events from the VMS.

<SpecDate> Page 4
 <SpecificationName>

3. System Integration

3.1. The ISMS shall support OPC AE protocol.

3.1.1. The OPC AE interface shall allow third party OPC clients to subscribe to
receive alarms and events from the ISMS.

3.1.2. When an alarm is processed, the OPC AE client shall send an event
processed message back to the ISMS to process the alarm on the ISMS.

3.1.3. The ISMS shall support multiple simultaneous OPC AE connections.

3.2. The ISMS shall support OPC DA protocol.

3.2.1. The OPC interface shall support OPC DA specification 2.0 and 3.0.

3.2.2. The OPC DA interface shall allow the status of system components to be
reported to an external OPC DA client.

3.2.3. The OPC Interface shall allow third party OPC DA clients to generate system
component overrides including but not limited to alarm zone and access
zone overrides.

3.2.4. The ISMS shall support multiple simultaneous OPC DA connections.

3.3. The ISMS shall support a REST Web Service API.

3.3.1. The ISMS cardholder functionality shall support a REST Web Service to allow
an external system to create, remove, and modify cardholders, including
assigning access rights.

3.3.2. The ISMS alarms and events functionality shall support a REST Web Service
to allow external systems to receive alarms and events from the ISMS.

3.3.3. The ISMS shall provide a REST Web Service that will allow a third-party
system to perform actions in the ISMS such as open doors, disarm alarm
zones, and turn an IFC output on.

3.3.4. The ISMS shall support a REST Web Service that will allow a third-party
system to interrogate the status of ISMS items such as doors, alarm zones,
and IFC inputs.

3.4. The ISMS shall allow data exchange with other applications using XML protocols.

3.4.1. The system shall provide an XML interface to allow for the import, export,
and synchronisation of data in an on-going basis from other applications
directly into the cardholder database both in a real-time manner and in a
batch-oriented approach. A developer’s kit with a sample application shall
be readily available.

<SpecDate> Page 5
 <SpecificationName>

3.4.2. The system shall provide an XML interface to allow for updating access
control schedules from other applications directly into the ISMS database in
both a real-time manner and in a batch-oriented approach. A developer’s kit
with sample application shall be readily available.

3.5. The system shall provide a tool which allows configuration and synchronisation of
cardholder data with third party systems via a csv file. The CSV import functionality
shall support the following functionality:

3.5.1. manually triggered data import,

3.5.2. schedule triggered data import,

3.5.3. images imported via flat file.

3.6. An API that communicates directly to the IFC shall be available.

3.6.1. The API shall allow third party systems to pass events to the IFC and for the
events to appear in the ISMS event window.

3.6.2. It shall be possible for the IFC to be programmed to trigger actions based
upon these external events. For example, a video analytic alarm from a
video management system is passed to the IFC, the IFC in turn will lock
doors and raise and alarm.

3.6.3. It shall be possible for a third-party system to send a card number and site
code to the IFC to act as a “virtual card reader”.

3.6.4. The API shall allow the third-party system to interact directly with the IFC
with no reliance on the ISMS server.

3.7. The ISMS shall support the BACnet communications protocol.

3.7.1. BACnet communication will be via TCP/IP.

3.7.2. The IFC will communicate with BACnet devices with no need for server
intervention.

3.7.3. The BACnet integration will enable the IFC to monitor BACnet objects for
state changes and raise alarms accordingly.

3.7.4. The BACnet integration will enable the IFC to change BACnet object states in
response to events.

3.8. The ISMS shall support the SNMP communications protocol.

3.9. Events from third party systems shall be managed in the same way as inputs
connected directly to IFCs.

3.10. Interactions with third party systems shall be logged in the ISMS.

<SpecDate> Page 6
 <SpecificationName>

4. Central Control and System Management Software

4.1. The ISMS servers shall use a Microsoft Windows operating system as defined
previously.

4.2. The system database shall be a version of Microsoft SQL Server appropriate for the
system size required. The version of Microsoft SQL Server is among those defined
previously.

4.3. The connection between ISMS and Microsoft SQL Server shall use Windows
Authentication.

4.4. The ISMS shall employ a high quality computer incorporating current generation
design and components. It shall be of a Microsoft approved model for operation with
current versions of Microsoft Windows operating systems. The hardware specification,
including processor speed, internal memory and hard disk size shall be specified by the
supplier and must be sufficient to meet or exceed the capacity and throughput of the
specified system.

4.5. The ISMS shall be capable of supporting a minimum of 20 hardware based operator
workstations running concurrently. Operator workstations running terminal emulation
software will not be accepted.

4.6. The ISMS shall automatically log and time/date-stamp all events within the system
including intruder alarm set/unset events, access control events, operator actions and
activity.

4.7. The configuration GUI shall make extensive use of menus and windows and require a
minimum of operator training to operate the system proficiently. Systems requiring a
script/program language approach to configure the system will not be accepted.

4.8. A free text notes/memo field shall be available for each logical/physical object to store
abstract information relating to that item.

4.8.1. The notes field shall support 128,000 characters of text.

4.8.2. The notes field shall support word-wrap, insert, delete, cut, copy and paste
functions.

4.9. The ISMS must be capable of receiving simultaneous alarm signals from remote
locations without loss or excessive delay in their presentation to the operator. Any
authorised operator should be allowed to acknowledge, view and/or process an alarm.

4.10. The ISMS shall be fitted with a real-time clock, the accuracy of which shall be
preserved over the period of main power supply failure. Time synchronisation
between the ISMS and Ethernet connected IFCs shall be automatic and not require
operator intervention.

<SpecDate> Page 7
 <SpecificationName>

4.11. Operator selection of processing tasks shall be via menu selections. Authorised
operators shall be able to process alarms, produce reports and modify database
records without degrading system performance.

4.12. The following is the minimum operational and monitoring facilities required. The
ability to:

4.12.1. program either a group or individual card readers with access control
parameters, without affecting other card readers,

4.12.2. program the access criteria for individual cardholders or groups of

cardholders,

4.12.3. store at least 64 non access control data fields for each cardholder. The
names of these data fields shall be user-definable,

4.12.4. authorise or de-authorise a cardholder in the system with the result

reflected immediately throughout all access points in the system,

4.12.5. enable a card trace against selected cardholders so that an alarm is raised
each time that cardholder presents their access card or token,

4.12.6. pre-program holidays so that different access criteria apply compared to

normal scheduled days. The system must have a capacity to set at least 400
holiday days,

4.12.7. recognise and manage regional holiday requirements,

4.12.8. define as many access zones as there are card readers fitted,

4.12.9. allow or disallow individual cardholder access to any one, or group of card
readers, in real-time,

4.12.10. log all ISMS and operator activity to hard disk as it is received at the ISMS
server,

4.12.11. program alarm response instructions into the system so that these are
presented to the operator when processing an alarm event,

4.12.12. enable an operator to enter messages against alarm events. This may be an
enforced operator operation based on configuration on a per operator basis,

4.12.13. configure user-definable short messages to allow the operator to enter

commonly used comments with minimal effort when entering messages
related to alarms. For example, false alarm, user error, etc. These messages
should also be assigned to keyboard shortcut keys to enable faster
commenting on alarms,

4.12.14. temporarily override a cardholder, or group of cardholders, pre-

programmed access criteria.

<SpecDate> Page 8
 <SpecificationName>

4.13. The operator GUI shall display a one-line plain language event message for every
activity event (alarm or otherwise) occurring in the system. All activity logged shall be
time and date stamped to the nearest second (hh:mm:ss). On having the appropriate
operator authorisation it shall be possible to drill down into the properties of each
component that makes up that event. The event message shall advise:

4.13.1. the time of event created at the IFC,

4.13.2. the time the event was received at the ISMS server,

4.13.3. the source of the event,

4.13.4. any successful or unsuccessful access attempt,

4.13.5. if the access attempt is unsuccessful, the reasons for the denial.

4.14. This includes but is not restricted to the following items:

4.14.1. all card attempts,

4.14.2. all door alarms,

4.14.3. all operator activity including logon, logoff, and alarm response messages,

4.14.4. all alarm monitoring activations,

4.14.5. all communication link failures.

4.15. Time schedules for different days shall be configurable.

4.16. Regional holidays shall be configurable to allow for regional variations.

4.17. The system shall provide a detailed operator help file. This help file shall provide
operators with text, audio, and video, help instructions and tutorials.

4.18. The system shall allow for searching of items configured within the system based on
the following:

4.18.1. item characteristics,

4.18.2. related items,

4.18.3. times related to events including within properties of a configured item

(creation and modification events).

4.19. The system shall integrate with Microsoft Active Directory enabling cardholder and
user records to be fully synchronised on a real-time, bi-directional basis.

4.19.1. Integrations that use third party applications to synchronise between

Microsoft Active Directory and the system shall not be acceptable.

<SpecDate> Page 9