Knowledge Base Article
Example Project involving
Scripting
Copyright © 2008-2012, ISONAS Security Systems
All rights reserved
Table of Contents
1: INTRODUCTION ... 3
1.1: PROBLEM DESCRIPTION: ... 3
2: LOCKDOWN SOLUTION ... 3
2.1: LOCKDOWN CARDS: ... 4
2.2: LOCKDOWN CARDS (ALTERNATE CONFIGURATION): ... 6
2.3: PUSH-BUTTON RESETS THE DOORS’ STATUS: ... 8
2.4: INRSERV CONFIGURATION:... 10
2.4: SCRIPT TESTING: ... 11
3: EMAIL NOTIFICATIONS... 12
3.1: EX-EMPLOYEE ACCESS ATTEMPT NOTIFICATION: ... 12
Document Version
(
KBA0060Scripting.Doc )
Date of Revision Revision Author Description 10/27/2008 1.0 Shirl Jones Initial Release
1: INTRODUCTION
This document describes an advanced installation, in which the Scripting features of the Crystal Matrix software are used.
By reviewing the example configurations, you should gain an understanding of the different ways you can set up the ISONAS system to meet your customer’s
requirements.
It is assumed that you are already comfortable and familiar with configuring the basic Who/When/Where concepts within the Crystal Matrix Software.
1.1: PROBLEM DESCRIPTION:
The Tropical High School (THS) is installing the ISONAS Access Control System. The facility is a five (5) story building, with an elevator, and multiple exterior and interior doors being controlled by the ISONAS Access Control System.
The part of the project that this document discusses includes: Initial Installation Requirements
Supply “lockdown” cards for both the Principal and Vice-principal. When these cards are used at any reader in the facility, the following doors go into lockdown mode: Front Lobby, Gym, LoadingDock, and EastSide
To help assure that the Principal or Vice-Principal realize that they just placed the school into lockdown mode, these card should be “rejected” and not open the doors.
Supply a push-button located in the school’s office that resets these doors back into their normal mode of operation.
As we will see, the “lockdown” cards solution’s design requires use of the Scripting feature.
In addition, the school will be using the Scripting sub-system’s Email
notification functionality to report on any ex-employees who are attempting to access the school.
2: LOCKDOWN SOLUTION
Note: Many times, there are multiple ways that the ISONAS system can be configured to accomplish a certain task. These examples demonstrate one configuration that addresses the client’s needs.
2.1: LOCKDOWN CARDS:
The basic “business rule” we are implementing here is: .
When:
A member of the “AuthLockDown” people-group, presents their badge at any reader-controller in the facility
Then:
Their badge will be rejected, and the exterior doors of the school will be placed into the “Lockdown” state.
Configuring the ISONAS system to support this feature requires:
1. Defining a Door Group “THS_AllDoors” that contains all doors in the system a. This Door Group is used when defining which doors the Lockdown
card can be presented to.
2. Defining a People Group “AuthLockDown” for those people who will have authority to place the school in the “lockdown” condition
3. Creating a 2nd Person entry for the Principal and a 2nd entry for the Vice-Principal in the Person database,
a. The person who is assigned these “lockdown” badges will have another badge that they normally use to access the facilities. The client requests that the lockdown badges be “rejected” when
presented to the doors. The action of rejecting these badges serves as a warning to the person presenting the card that they just placed the school into the “lockdown” condition.
b. Assign these 2nd People entries to the AuthLockDown group c. The Unique ID for each person’s 2nd entry will start with the text
“LockDown” as a reminder of the purpose of this entry. d. Assure that there is no permission defined that gives the
AuthLockDown Group access to any location. 4. Assign the “Lockdown Badges” to each person’s 2nd entry.
5. Define the Script that places the exterior doors into the lockdown mode. a. Define the action that initiates the Script as shown below
i. A card belonging to a person assigned to the AuthLockDown Group
ii. Was presented to a door in the THS_All Door Group iii. And the card was rejected.
b. Define the Script itself as shown
<REMARK> Tropical High School Exterior Lockdown Script | <REMARK> Script last modified: 10/25/2008 by Tom |
<LOCKDOWN><THS_FrontLobby>| <LOCKDOWN><THS_Gym>|
<LOCKDOWN><THS_LoadingDock>| <LOCKDOWN><THS_EastSide>|
c. Please note that the syntax of the Scripting commands are documented in the “ISONAS Scripting and TCP/IP Interface” document that can be found in application’s sub-directory ..\ISONAS\Docs
2.2: LOCKDOWN CARDS (ALTERNATE CONFIGURATION):
An alternative configuration would remove the need for a 2nd entry in the People database for the Principal and Vice-Principal.
It uses the “Count Limitation” feature of the Crystal Software. If the site uses “Count Limited” for other purposes, then a careful review should be done to assure that neither the Principal nor the Vice-Principal would have another reason to use another credential that could also be Count Limited.
Configuring the ISONAS system to support this feature requires:
1. Defining a Door Group “THS_AllDoors” that contains all doors in the system a. This Door Group is used when defining which doors the Lockdown
card can be presented to.
2. Defining a People Group “AuthLockDown” for those people who will have authority to place the school in the “lockdown” condition
3. Assign the “Lockdown” badges to the Principal and Vice-Principal
a. Modify these badges so they are “count limited” and the remaining count is zero (0)
4. Define the Script that places the exterior doors into the lockdown mode. a. Define the action that initiates the Script as shown below
i. A card belonging to a person assigned to the AuthLockDown Group
ii. Was presented to a door in the THS_All Door Group iii. And the card was rejected with a “Reject – Overlimit”
condition.
b. Define the Script itself as shown
<REMARK> Tropical High School Exterior Lockdown Script | <REMARK> Script last modified: 10/25/2008 by Tom |
<LOCKDOWN><THS_FrontLobby>| <LOCKDOWN><THS_Gym>|
<LOCKDOWN><THS_LoadingDock>| <LOCKDOWN><THS_EastSide>|
c. Please note that the syntax of the Scripting commands are documented in the “ISONAS Scripting and TCP/IP Interface” document that can be found in application’s sub-directory ..\ISONAS\Docs
2.3: PUSH-BUTTON RESETS THE DOORS’ STATUS:
The School’s office will have a push-button installed, which will be tied into the office’s ISONAS reader-controller AUX input.
When activated, the AUX input will run a script to place the exterior doors back into their normal status.
1. Define the Script that places the exterior doors into the lockdown mode. a. Define the action that initiates the Script as shown below
b. Define the script as shown.
<REMARK> Tropical High School Return to Normal Script | <REMARK> Script last modified: 10/25/2008 by Tom | <RESETNORMAL><THS_FrontLobby>|
<RESETNORMAL><THS_Gym>|
<RESETNORMAL><THS_LoadingDock>| <RESETNORMAL><THS_EastSide>|
c. Assure that the THS_Office Door is configured to use the People/ Permissions databases to validate the AUX input.
d. Add a Permission to authorize the AUX input for 24 hours a day, 7 days a week.
i. In the example above the Group “AUX Button” exists, and the AUX person is assigned to that group. The Shift “Always” exists, and is valid 24x7.
2.4: INRSERV CONFIGURATION:
The Crystal Matrix INRServ process handles the processing of Scripts and the events that initiate the scripting.
The full documentation on the INRServ process is found in the “ISONAS Script and TCP/IP Interface” document.
You can find a copy of this document in the ..\Program Files\ISONAS\Docs folder.
2.4: SCRIPT TESTING:
The school has a put a plan in-place to periodically test the scripts. Testing will be done on either a monthly or bi-monthly basis.
This will assure that any other Crystal Matrix configuration changes that have been made have not prevented the lockdown scripts from properly doing their job. Two examples of configuration changes that could affect the scripts would include:
o The School decides to rename the doors within the Crystal Software package. The scripts would need to be updated with the new door names.
o The server running the access system is reconfigured to no longer run the Crystal Matrix INRServ process.
This testing also assures that the Lockdown cards are readily available to the Principal and Vice-Principal.
3: EMAIL NOTIFICATIONS
The Crystal Matrix Email notification feature is very powerful and flexible. You have control to:
• Select the System Events that initiate the emails • Select who the emails are sent to
• Define the content of the email message
• Optionally include event specific information in the email
To illustrate the strength of the email facility, an example usage is described below.
3.1: EX-EMPLOYEE ACCESS ATTEMPT NOTIFICATION:
The school district would like to be warned by email if an ex-employee has attempted to enter the facility using their old credential.
Procedurally, the school will handle an employee who has left by:
Deactivate the employee’s access by removing all of their current PeopleGroup assignments
Assigning that person to the “Ex-Employees” PeopleGroup.
The Crystal Matrix configuration used to accomplish the email notification is: 1. The system will have a PeopleGroup defined for “Ex-Employees” 2. The Ex-Employee PeopleGroup will not be used by any Permissions.
3. A Script will be defined that runs whenever a member of the Ex-Employee PeopleGroup is “rejected” at any door.
4. This Script will generate a notification email that is sent to the school district’s security office and human resources department.
3.1.1: SYSTEM CONFIGURATION FOR EX-EMPLOYEE HANDLING:
1. Define the Script that generates the email notification.
a. Define the action that initiates the Script as shown below
i. A card was presented to a door in the THS_All Door Group ii. The card belonged to a person assigned to the Ex_Employee
PeopleGroup
iii. And the card was rejected.
b. Define the script as shown.
<REMARK> Tropical High School ExEmployee Access Attempt| <REMARK> Script last modified: 10/25/2008 by Tom |
<QUEUE EMAIL><[email protected];[email protected]><20> <Ex-Employee Attempted Access>
<Please notify School Security @ 333-456-7878> <---><EVENT DATA>|
This script will send the email to two recipients. There will be a 20 second delay before the email is sent, to allow the system to combine multiple access-attempts into a single email. The “EVENT DATA” entry adds the details of the access-attempt to the email.
2. Configure the Scripting System’s Email Notification settings.
The INRServ’s TCP/IP configuration window contains the email notification settings. Below is shown the school’s configuration.
