New approaches to building ACS using WEB-technologies
The development of technology has had a significant impact on the architecture of access control systems. Having followed the path of its development, we can predict what awaits us in the near future.
Once upon a time, computer networks were still a rarity. And then ACSs were built as follows: the master controller served a limited number of controllers, and the computer acted as a terminal for its programming and display of information. The logic of work was determined by the master controller that controls the secondary controllers.
Secondary controllers could not exchange information directly with each other, the exchange took place through the master controller. This model imposed significant restrictions on the development of access control systems.
The development of computer technology and network equipment influenced the architecture of the systems, as a result of which multiserver access control systems appeared. The changes affected the software, but bypassed the controllers, which imposed a limitation on the expansion and development of the system.
The development of microelectronics has enabled equipment manufacturers to fundamentally change the architecture of access control systems. The previous model was replaced by an architecture in which controllers were able to exchange data directly with each other.
In this model, the software could be installed anywhere within the local network; integration with other security systems was simplified by using a single information exchange environment.
This model has been successfully operating to this day, but the current level of technological development allows us to build systems with a completely different architecture. There is a wide range of physical and logical options for providing communication between system components and means of interaction between users and the system. Among them are console applications, specialized controllers with a graphical interface, various control panels, tablet computers and phones, the use of standard WEB browsers. The capabilities of microcontrollers are many times greater than the resources of computers used in the first ACS.
Controller as server
The server in the ACS is needed to correctly execute the business logic of the system, to store data about users and events. 20 years ago, the master controller also dealt with this. Since then, the requirements for access control systems have increased significantly, but the capabilities of modern controllers exceed the capabilities of computers 20 years ago.
The system server can be installed in the controller itself, if it has the appropriate resources. A system server deployed in controller memory has significant advantages. The first of these is the ease of starting the system.
One of the system controllers is assigned by the server (or by the master, as it once was), it receives instructions with which controllers it will work with. Everything, the system is ready. To work with remote objects, the controller assigned by the server is given a “white” IP, it is indicated to other controllers, and they independently connect to it. To integrate with 1C, you just need to transfer the controller address to the program. To integrate with the license plate recognition system, specify the vehicle number and the IP address of the camera or system capable of recognizing car numbers as the pass number.
ACS as a service
The second major benefit is user friendliness. The customer no longer needs to think on which computer to deploy the system to, where he will stand, and who will serve him. Now the client simply receives an IP address, login and password - and can monitor employee discipline, assign access rights and issue guest passes in any browser that suits him. It is enough to purchase a turnstile and a controller (or a turnkey solution - an electronic checkpoint) and identifiers. And the system is ready.
This approach maximally meets the current trend of perception of ACS as a service. The customer does not think about installing and maintaining the system, all this is remotely carried out by specialists. Here the question inevitably arises about the speed of the controller and its ability to work with 10 thousand users and 200 turnstiles? While this is not possible, but the database can be located in the cloud or on a dedicated server. Over time, the capabilities of controllers will grow, and the system described above can be deployed even in large enterprises with a large number of employees and executive devices.
Standardization as a trend
The ACS architecture will be built on the basis of “smart” controllers that will independently interact with each other, having among themselves several master controllers that act as a server. They can also be combined on the basis of a single server (or several servers), which provides the necessary interaction logic.
It is necessary that the standardization of protocols be supported by all market players - not only at the level of interaction with the controller, but also at the level of system interaction.
Perhaps the development of a single standard will be implemented in the distant future. But even if this does not happen, standardization of interactions based on the REST API and access to information through the browser should be implemented as soon as possible.
Past
Once upon a time, computer networks were still a rarity. And then ACSs were built as follows: the master controller served a limited number of controllers, and the computer acted as a terminal for its programming and display of information. The logic of work was determined by the master controller that controls the secondary controllers.
Secondary controllers could not exchange information directly with each other, the exchange took place through the master controller. This model imposed significant restrictions on the development of access control systems.
The development of computer technology and network equipment influenced the architecture of the systems, as a result of which multiserver access control systems appeared. The changes affected the software, but bypassed the controllers, which imposed a limitation on the expansion and development of the system.
The present
The development of microelectronics has enabled equipment manufacturers to fundamentally change the architecture of access control systems. The previous model was replaced by an architecture in which controllers were able to exchange data directly with each other.
In this model, the software could be installed anywhere within the local network; integration with other security systems was simplified by using a single information exchange environment.
This model has been successfully operating to this day, but the current level of technological development allows us to build systems with a completely different architecture. There is a wide range of physical and logical options for providing communication between system components and means of interaction between users and the system. Among them are console applications, specialized controllers with a graphical interface, various control panels, tablet computers and phones, the use of standard WEB browsers. The capabilities of microcontrollers are many times greater than the resources of computers used in the first ACS.
Further development of access control architecture
Controller as server
The server in the ACS is needed to correctly execute the business logic of the system, to store data about users and events. 20 years ago, the master controller also dealt with this. Since then, the requirements for access control systems have increased significantly, but the capabilities of modern controllers exceed the capabilities of computers 20 years ago.
The system server can be installed in the controller itself, if it has the appropriate resources. A system server deployed in controller memory has significant advantages. The first of these is the ease of starting the system.
One of the system controllers is assigned by the server (or by the master, as it once was), it receives instructions with which controllers it will work with. Everything, the system is ready. To work with remote objects, the controller assigned by the server is given a “white” IP, it is indicated to other controllers, and they independently connect to it. To integrate with 1C, you just need to transfer the controller address to the program. To integrate with the license plate recognition system, specify the vehicle number and the IP address of the camera or system capable of recognizing car numbers as the pass number.
ACS as a service
The second major benefit is user friendliness. The customer no longer needs to think on which computer to deploy the system to, where he will stand, and who will serve him. Now the client simply receives an IP address, login and password - and can monitor employee discipline, assign access rights and issue guest passes in any browser that suits him. It is enough to purchase a turnstile and a controller (or a turnkey solution - an electronic checkpoint) and identifiers. And the system is ready.
This approach maximally meets the current trend of perception of ACS as a service. The customer does not think about installing and maintaining the system, all this is remotely carried out by specialists. Here the question inevitably arises about the speed of the controller and its ability to work with 10 thousand users and 200 turnstiles? While this is not possible, but the database can be located in the cloud or on a dedicated server. Over time, the capabilities of controllers will grow, and the system described above can be deployed even in large enterprises with a large number of employees and executive devices.
Future
Standardization as a trend
The ACS architecture will be built on the basis of “smart” controllers that will independently interact with each other, having among themselves several master controllers that act as a server. They can also be combined on the basis of a single server (or several servers), which provides the necessary interaction logic.
It is necessary that the standardization of protocols be supported by all market players - not only at the level of interaction with the controller, but also at the level of system interaction.
Perhaps the development of a single standard will be implemented in the distant future. But even if this does not happen, standardization of interactions based on the REST API and access to information through the browser should be implemented as soon as possible.
All Articles