The TESA Access Control system is basically designed to manage electronic cylinders, electronic locks and/or off-line wall readers.

Transcription

1 TS1000 Grant Names

2 Introduction The TESA Access Control system is basically designed to manage electronic cylinders, electronic locks and/or off-line wall readers. When an off-line system is running, every time the closure plan is modified the new data must be transferred to the doors involved using the Portable Programmer. The TESA Access Control system allows specific parameters to be established for granting or denying user access to a door (or group of doors) when the user credentials are registered, thus avoiding the need to physically go to the door. These parameters are known as Permits. Operating without Permits Once the installation is complete, when we work without permits, the operating sequence of the cylinders, locks and/or readers is as follows: The cylinders, locks and/or readers have a closure plan stored in the memories of their control units. When the user inserts or approaches with her or his credentials, a reader reads the information stored in the credentials and transmits it to the control unit. When a user wishes to open a door, the control unit will verify the credential complies with the following requirements: System code The system code recorded on the credential must coincide with the code recorded on the facility. Activation date and expiry If the coded credential has a start date activated, this must be earlier than the date and time when the attempt to open is made. If the coded credential has an expiry date, this must be later than the date and time when the attempt to open is made. Matrix The user must have access to the system matrix (closure plan). This can be Always or in accordance with one of the established Zone Times. If the credential complies with the three requirements, the user will be able to open the door. If not, the request to open it will be denied. ANEXO: PERMISSIONS 2

3 With this mode of operation, every time we need to grant or deny user access to a door, we must take the follow steps: Modify the closure plan: cross User/Door in the Matrix. Transmit the data to the Portable Programmer. Physically travel to the door with the Portable Programmer and update it, i.e. update the closure plan stored in the door s control unit. This process, depending on how often we need to repeat it, can be rather inconvenient. Nevertheless, it is something we can avoid having to do if we use the so-called Permits. Operating with Permits A permit is an additional parameter we voluntarily input on the system. This parameter becomes an additional condition required from the users by a door or group of doors, i.e. users need a permit to open a door, and must be in possession of the permit. Whether or not the user has the permit is stored on the user credential and therefore, is a factor we can decide on when we record it. The sequence is as follows: The cylinders, locks and/or readers, have the closure plan stored in their control units. When the user inserts or approaches with her or his credentials, the reader module reads the information stored in the credentials and transmits them to the control unit. For the user to be able to open the door, the control unit will verify the credentials meet the following requirements: System code. Activation and expiry dates. Matrix. Permission. The user credential must contain the permit required for the door. Therefore, when we want to deny a user access to a door for which she or he has an access permit, all we need to do is re-record the user credential, omitting the permit. There is no need to modify the closure plan, and therefore there is no need to travel to the door with the Portable Programmer. ANEXO: PERMISSIONS 3

4 Activating Permits Defining permits: To use permits, the first step we must take is to define the permits required. These are defined in the tab Grant Names in the Installation menu, where the system allows up to 14 different permits to be defined. Example: let s suppose we want to create a permit for the Warehouse door of a facility. We will type the word WAREHOUSE in field 1. ANEXO: PERMISSIONS 4

5 Assigning permits to doors: When we create a permit, a new option Requires permit will automatically appear in the System Doors menu. If this field is empty it means the door in question does not require any permits and therefore it will function according to the system described above in the section OPERATING WITHOUT PERMITS. Example: to assign a permit to a specific door. In this case we will choose the Warehouse door. The Requires Grant option is a drop-down menu of the permits defined by the system. In this group we will see the WAREHOUSE permit. This is the one to which we will assign the Warehouse door. WAREHOUSE Note: One permit can be assigned to several doors. For example, the FLOOR 1 permit can be assigned to all the doors on FLOOR 1. ANEXO: PERMISSIONS 5

6 Matrix: For the permit function to be really effective, it is recommended that all the users be granted access to doors requiring permission. Authorised access can be according to the Always time zone or according to time limitations established on the system (Zone Times). Therefore, a user will be granted or denied access to a door requiring permits depending solely on whether or not the user has been granted a permit. To continue with the example, we must give access to all users of the Warehouse door. Warehouse door: All users have access according the Always Time Zone. Updating doors: Once the above steps are complete and so that the permits start functioning, we must update the doors in question (When we first introduce the system, we must Start the doors instead of Updating them). To so this we must: Transmit the data to the Portable Programmer.Transmitir los datos al programador portátil. Update and/or start the affected doors. Continuing with the example: we must update the Warehouse door. ANEXO: PERMISSIONS 6

7 Assigning permits to users: Similarly to the Doors menu, when we define permits on the system, a new field will automatically appear in the new field called Permits in the user menu. This field contains the list of permits available on the system. Each permit has a selection form, where a blank field means the user has not been granted permission. When we want to give a permit to a user, all we need to do is select the user and assign the permit to her or him. We can change the permits assigned as many times as we wish. All we need to do is record the user credentials again when we modify the assignment. Example: If we assign the WAREHOUSE permission to the user Bienvenido Calvo, we will see: That is how we finish setting up the permits for a facility. ANEXO: PERMISSIONS 7

8 Example of Application Managing the whole installation with permits When a facility has fewer than 14 doors, a permit can be defined for each door. This means we can design a matrix in which all users are granted access to all the doors. This can be Always or for a specific time zone. Therefore, whether or not a user has access to any given door at a facility will depend solely on the permits and not on the matrix. In a facility such as this, we only need to go to the doors with the Portable Programmer when we want to collect the opening register and/or when we need to add users to the system. Visit management Generally speaking, visitor management problems at a facility are: We do not know who the visitors will be. We do not know how many visitors there will be. We do not know whom the visitor is going to see and how long she or he will need access for. And we do not know how long the person will be on the premises. The use of permits helps with this management. To do this we will define a user group called Visitors. We will call them visitor 1, visitor 2, visitor 3.. visitor X, where X is the maximum number of visitors expected per day. Users in this group will be granted access according to the time zone for the door or doors we consider appropriate. These doors or groups of doors will require one of the permits defined. Therefore, when a possible visitor arrives, we just select the user number Visitor X available. We can give the visitor the permits necessary for the visit in question. And we assign the expiry time and date. When this date has passed, the Visitor X credential will be available for another visitor once more. Using this system, the only factor we are not managing is the visitor s name. But this is an aspect that can be managed using another programme. ANEXO: PERMISSIONS 8

9 ANEXO: PERMISSIONS 9