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 | 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. |
^(?(“”)(“”.+?””@)|(([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 | 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.