How can we help?
< All Topics
Print

Appendix D – Sample Data Configuration

Sample Roles

ARCO includes built-in standard Roles Types that define the most commonly used ways of accessing features. Except for the Administrator role, you can modify or delete all common roles.

Role

Description

Dashboard

Administrator

This role manages the system, and it has access to all functions within the system

This role already exists. It can’t get deleted

Menus: All

Display system monitoring related information, including uptime, service status, etc.…

Card Enrolment

This operator creates users within the system for new employees and assigns credentials and permissions to them

They should see the “users” menu and submenus. They can add, delete, edit user information, but have view-only access on roles

They might be able to view user access logs

Display user-related information (Number of users, user activity, etc.)

Personnel Manager

This operator has all the functions of the “Card Enrolment” user, plus has the ability to define role permissions

Similar to Card Enrolment

Alarm Monitoring

This operator is concerning with responding to alerts within the system

They can view sites, profiles, events, users. They can perform actions on “Alarm” objects (Not added to the system yet). They can perform actions on site-related objects (Open doors, isolated points, etc.)

Display alarm related information, outstanding alerts, actions alerts, Map of alarms, etc.…

Reporting User (e.g. Security Head)

This user might need to generate reports on the system, based on how long it took to activate an alarm, fix a faulty door, unusual access activity, power consumption, temperature, etc.…

They probably need view access to everything within the Site. They can create reports and visualisations.

Customised data showing common report visualisations

Technician

This operator might occasionally use the web interface, and often use a basic interface on their mobile device

They can edit profiles, add a site to the system, move a site to a new profile (usually)

They need to see events and status-related information for a specific site

They cannot action alarms, or view user details (usually)

Display a list of faults in the system on a map

Site/ATM Technician

This user does not use the ARCO Platform interface but has a card and access devices on the keypad

They can perform actions on devices for a specific site that they have been granted access to for the day. Sometimes they will have permission for all sites at any time of day, and in this case, the system will record that the technician accessed the site

Once every few months they might log into the system to change their PIN (Future development)

 

Basic Cardholder

This user does not use ARCO Platform but might be an office worker that needs to access specific doors at their regular place of employment

They will perform the “access” action on doors within the system, by swiping their card at the reader next to the door

Once every few months they might log into the system to change their PIN (Future development)

 

Advanced Cardholder

This user does not use the ARCO Platform, but might be an office worker that needs to access specific doors at their regular place of employment, and might need access to several sites

They will perform the “access” action on doors within the system, by swiping their card at the reader next to the door

Once every few months they might log into the system to change their PIN (Future development)

 

Sample Regular Expressions

Field

Expression

Format Samples

Description

Name

^[a-zA-Z”-‘\s]{1,40}$

John Doe O’Dell

Validates a name. Allows up to 40 uppercase and lowercase characters and a few special characters that are common to some names.

Social Security Number

^\d{3}-\d{2}-\d{4}$

111-11-1111

Validates the format, type, and length of the supplied input field. The input must consist of 3 numeric characters followed by a dash, then 2 numeric characters followed by a dash, and then 4 numeric characters.

Phone Number

^[01]?[- .]?(\([2-9]\d{2}\)|[2-9]\d{2})[- .]?\d{3}[- .]?\d{4}$

(425) 555-0123
425-555-0123
425 555 0123
1-425-555-0123

Validates a phone number. It must consist of 3 numeric characters, optionally enclosed in parentheses, followed by a set of 3 numeric characters and then a set of 4 numeric characters.

E-mail

^(?(“”)(“”.+?””@)|(([0-9a-zA-Z]((\.(?!\.))|[-!#\$%&’\*\+/=\?\^`\{\}\|~\w])*)(?<=[0-9a-zA-Z])@))(?(\[)(\[(\d{1,3}\.){3}\d{1,3}\])|(([0-9a-zA-Z][-\w]*[0-9a-zA-Z]\.)+[a-zA-Z]{2,6}))$

someone@example.com

Validates an e-mail address.

URL

^(ht|f)tp(s?)\:\/\/[0-9a-zA-Z]([-.\w]*[0-9a-zA-Z])*(:(0-9)*)*(\/?)([a-zA-Z0-9\-\.\?\,\’\/\\\+&%\$#_]*)?$

http://www.microsoft.com

Validates a URL

ZIP Code

^(\d{5}-\d{4}|\d{5}|\d{9})$|^([a-zA-Z]\d[a-zA-Z] \d[a-zA-Z]\d)$

12345

Validates a ZIP Code. The code must consist of 5 or 9 numeric characters.

Non- negative integer

^\d+$

0
986

Validates that the field contains an integer greater than zero.

Currency (non- negative)

^\d+(\.\d\d)?$

1.00

Validates a positive currency amount. If there is a decimal point, it requires 2 numeric characters after the decimal point. For example, 3.00 is valid, but 3.1 is not.

Currency (positive or negative)

^(-)?\d+(\.\d\d)?$

1.20

Validates for a positive or negative currency amount. If there is a decimal point, it requires 2 numeric characters after the decimal point.

Sample Access Scenarios

Scenario 1 – Access a door with an invalid card

Present a card on a reader that is configured to be on a door and verify that a valid card will not access the door and generate an invalid LED on the reader. Nothing else should happen at the door.

Scenario 2 – Access a door with a valid card

Present a card on a reader that is configured to be on a door and verify that a valid card will access the door. There should be a “valid card” event generated and a valid LED on the reader. When the door is accessed test the following scenarios

  • – Strike time will activate, and if the door is not opened during the shunt time there is an event “ access not taken”
  • – Strike time will activate and if the door is opened and then closed during the shunt time there is an event “ access taken”
  • – Strike time will activate and if the door is opened and then left open up to the embarrassment time there is an event “access taken” and the buzzer starts on the keypad and then if the door is closed the buzzer will stop.
  • – Strike time will activate and if the door is opened and then left open up to the embarrassment time there is an event “access taken” and the buzzer starts on the keypad and then if the door is not closed an “Ajar” event is generated and after this when the door is closed the buzzer will stop and then an “Ajar reset” event is generated.

Scenario 3 – Force open a door

If the Door is opened without a valid access card or command, then a Door ‘Forced” event should be generated and the buzzer on the keypad should start. When the Door is closed and the door contact reset then there should be a Door “Forced Reset” event generated.

Scenario 4 – Access a door with egress

Press the egress input to access the door. There should be a “Door Accessed by egress” event generated and a valid LED on the reader. When the door is accessed test the following scenarios

  • – Strike time will activate and if the door is not opened during the shunt time there is an event “ access not taken”
  • – Strike time will activate and if the door is opened and then closed during the shunt time there is an event “ access taken”
  • – Strike time will activate and if the door is opened and then left open up to the embarrassment time there is an event “access taken” and the buzzer starts on the keypad and then if the door is closed the buzzer will stop.
  • – Strike time will activate and if the door is opened and then left open up to the embarrassment time there is an event “access taken” and the buzzer starts on the keypad and then if the door is not closed an “Ajar” event is generated and after this when the door is closed the buzzer will stop and then an “Ajar reset” event is generated.

Test 5 – Access a door with a command

Send a command from Arco to Access a door. There should be a “Door Accessed by command” event generated and a valid LED on the reader. When the door is accessed test the following scenarios

  • – Strike time will activate and if the door is not opened during the shunt time there is an event “ access not taken”
  • – Strike time will activate and if the door is opened and then closed during the shunt time there is an event “ access taken”
  • – Strike time will activate and if the door is opened and then left open up to the embarrassment time there is an event “access taken” and the buzzer starts on the keypad and then if the door is closed the buzzer will stop.
  • – Strike time will activate and if the door is opened and then left open up to the embarrassment time there is an event “access taken” and the buzzer starts on the keypad and then if the door is not closed an “Ajar” event is generated and after this when the door is closed the buzzer will stop and then an “Ajar reset” event is generated.

Scenario 6 – Access a door with a valid card and PIN

Set up a schedule to be Card and PIN. Set a PIN for the user in Arco. Present a card on a reader that is configured to be on a door and verify that the reader accept LED will flash waiting for a PIN. Enter a valid PIN to access the door. There should be a “valid card” event generated and a valid LED on the reader and the Door strike should activate.

Scenario 7 – Access a door with a valid card or PIN

Set up a schedule to be Card or PIN. Set a PIN for the user in Arco. Present a card on a reader that is configured to be on a door and verify access of the door. There should be a “valid card” event generated and a valid LED on the reader and the Door strike should activate. Repeat the test with a PIN instead of a card and same thing should happen.

Scenario 8 – Lock schedule

Set up a schedule to be locked on a Door. When this schedule goes active the door will remain locked. The denied LED will be on the reader, and an event will be generated “Door Locked”. When the schedule becomes inactive the door will go back to normal state and reader LED will go off and event “Door restored” generated. Test while the door is locked that no valid or invalid cards are allowed access to the door. There should be events generated whenever this happens.

Scenario 9 – Unlock schedule

Set up a schedule to be unlocked on a Door. When this schedule goes active the door will remain unlocked. The accept LED will be on the reader, and an event will be generated “Door unlocked”. When the schedule becomes inactive the door will go back to normal state and reader LED will go off and event “Door restored” generated. Test while the door is unlocked that valid cards are allowed access to the door and invalid cards are denied. There should be events generated whenever this happens.

Scenario 10 – Lock schedule and Unlock schedule at the same time

Set up a schedule to be locked on a Door and unlocked on a Door at the same time. When this schedules go active the door will remain locked. The denied LED will be on the reader, and an event will be generated “Door Locked”. When the schedule becomes inactive the door will go back to normal state or the unlocked state depending on the schedule time and reader LED will go off or accept LED on and event “Door restored” or “Door Unlocked” generated. Test while the door is locked that no valid or invalid cards are allowed access to the door. There should be events generated whenever this happens.

Previous Appendix C – Event List Definition
Table of Contents