1.

1 <SpecificationName>

1. Multiple Server Connectivity

1.1. ISMS based on multiple servers shall be supported.

1.2. Each server shall communicate directly with its local IFCs.

1.3. Should a network failure occur between servers, each shall continue to communicate
with their local IFCs.

1.4. Should a network failure occur between servers, operators shall be able to continue to
manage the local system connected to their respective servers. This includes (but is
not limited to) the following functions:

1.4.1. manage alarms,

1.4.2. override and manage doors,

1.4.3. arm and disarm alarms,

1.4.4. edit cardholders,

1.4.5. run reports.

1.5. Alarms and events from all servers shall be able to be displayed on any or all of the
system workstations.

1.6. The cardholder database shall be automatically replicated to all servers as a global
entity.

1.7. Replication of cardholder changes shall occur as changes are made and not batch
processed.

1.8. Communication between servers shall be peer to peer.

1.9. The multiple server environment shall allow for evacuation reports for each site on the
multiple server system to be generated on one server, for one or more remote servers.

1.10. Operator GUI views and program access privileges shall follow the same rules across
multiple servers as apply within a single server.

1.11. ISMS items configured on existing servers shall automatically be recognised by any
servers added to the multiple server group. Likewise, ISMS items configured on the
server(s) being added shall be automatically recognised by the existing multiple server
group.

1.12. Use of software interface custom written modules or scripts to connect servers into a
multiple server configuration shall not be permitted.

<SpecDate> Page 1
1.1 <SpecificationName>

1.13. Manual or script re-entry of data for existing servers into any new servers being added
to the multiple server group shall not be permitted.

1.14. Synchronisation of data across all servers shall be an automatic real-time function not
requiring operator intervention or initialising.

1.15. Should communication be lost between two or more servers, the individual servers
shall continue to function independently and shall resynchronise all changes made
whilst off-line automatically after reconnection to peer servers.

1.16. Should a conflict occur resulting from two items being created in two or more servers
whilst servers are off line then an alarm shall be raised when the servers are re-joined
advising of the conflict.

1.17. Should an existing record be modified in two or more servers whilst the servers are off
line then on reconnection, the modifications shall be carried out in time order of the
modifications.

1.18. There must be a native tool within the operator GUI to remove redundant servers
from a multiple server configuration. The use of scripts or external applications is not
allowed.

<SpecDate> Page 2
 <SpecificationName>

<SpecDate> Page 3