Le saviez-vous ?

BEHAVIOUR OF SEVERAL CENTRAL UNITS IN MDS ACCESS CONTROL SYSTEM

21 décembre 2011

In this article we will explain how the central unit sends the information related to a specific user, requested by another central unit in the system.

BEHAVIOUR OF SEVERAL CENTRAL UNITS IN MDS ACCESS CONTROL SYSTEM:

Introduction:

In MDS Access Control systems, using Wincom+, we can add up to 1024 users per central unit Ref.2405 in our system. In these cases, how the system behaves when it has to transfer the information between the central units? In this article we will explain how the central unit sends the information related to a specific user, requested by another central unit in the system.


Case of Study:

We will focus this explanation in the following case of study, composed by the following elements:

  • 2 x Ref.2405 MDS Central Unit.
  • 1 x Ref.6992 Cityline Proximity reader.
     
  • 1 x User A which passes its own ID card.
 
   

 

How the system works:

Regarding this case of study, we should pay attention to the versions of the central units, because depending on this version the behaviour is different.

VERSION 4.3 & PREVIOUS ONES

When the user A swaps the card, if this user does not appear in CU1’s database (table) the CU1 will ask if this user belongs to other CU. In this case, CU2 has this user stored, so it will send to CU1 the user and its profile number (USER + PROFILE INFO). The CU1 will take this info and it will look in its OWN database in order to see if this user can access or not depending on the profile.

EXAMPLE 1:

       
       
                       
     
 
     
 
     
     
 
 
     
 
   

EXAMPLE 2:

             

 

 

 

 

       
     
       
 
       
 
 
     
     
 
 
   

VERSION 5.2 ONWARDS

When the user A swaps the card, if this user does not appear in CU1’s database (table) the CU1 will ask if this user belongs to other CU. In this case, CU2 will check if the user A has access to the reader 1 but, in this case, considering own profile. Therefore, will send through the FXL if the user exists and, additionally, that he has access through reader 1 (taking into account the timetable as well).

 

 

Conclusion

Depending on the version of the CENTRAL UNIT, the protocol is different and therefore the behaviour of the system:

  • In the first case (old version) the CU2 sends the user and its profile number, so depending on this profile in CU1, the user will be allowed to pass or not.
     
  • In the second one (new versions) the CU2 sends the user and if this user should pass or regarding the CU2’s profile table (not to the CU1’s). The CU1 will act according to this information.