ACS, today.
ACS, today.
The market of technical security equipment is certainly reasonably conservative in terms of accepting certain technical innovations coming to it from related industries, and above all from the IT industry. On the one hand, the specifics of the TSB market business do not allow for the emergence of another “miracle novelty” to rush to offer it to clients in order to avoid the emergence of possible gaps in the organization of the facility’s protection. In addition, the turnover of funds in the TSB market is not as large as in the IT market, and any manufacturer must be sufficiently motivated by the client’s demand for a particular technical innovation in order to invest in its development (often from scratch) and production.
On the other hand, in my opinion, the policy of demonstratively ignoring by some of the market participants some inevitable, I would say “tectonic” processes of changing the conditions in which the TSB market is proposed to develop further, is also wrong. Therefore, without calling on anyone to “run with their pants up for the Komsomol”, I would like to dwell on those aspects of the development of the ACS market that will be relevant in the near future for all serious “players” in this TSB segment.
Controller software.
The control controller of the “new wave” ACS is most often a device based on an industrial PC with its own operating system, usually Linux. Moreover, the minimization of the response time to external signals in this case occurs not only through the emergence of new and increasingly productive processors for these devices, but also through programming these controllers for the specific functional tasks they perform. In other words, the controller at point A ensures the operation of the turnstiles at the checkpoint of the enterprise, and the controller at point B is exclusively engaged in monitoring the passage through a group of doors in the office sector of the building. The very idea of specializing controllers is absolutely not new, it’s just that using today's technologies, the programmable functionality of the controllers can subsequently be easily changed, for example, during the reconstruction of the building or changes in the general security policy at the facility.
Manufacturers have different points of view on the question of who, how and when can change the functionality of the controller. Some ACS manufacturers supply third-party software developers with a special SDK describing the possible functionality of the controller limited to certain limits. The AEOS (Nedap) ACS controller software offers a constantly expanding library of so-called “behavioral” components that allow the system user not only to quickly change the functionality of the controllers directly at the facility by using standard library components (checkpoint with a turnstile, airlock vestibule, passage through a standard door), but also to create new components of this library. At the same time, the user does not need knowledge at the level of a software developer for controllers under the Linux OS. The toolkit for creating new types of passage points is top-level software in which all system components are presented as a set of input and output modules of the system's hardware devices, which are logically connected to each other in the form of block diagrams describing the necessary algorithms for the operation of specific passage points.
In addition to the advantages in performance and flexibility of controller settings, this approach allows the customer of the system to achieve significant cost savings when changing the structure of the existing system at the facility (its expansion, transfer, change of control modes), since in this case there is often no need to purchase new expensive system controllers, and only their reconfiguration is required.
Another serious advantage of using controllers with an embedded Linux OS is the convenient
Use of Ethernet (TCP/IP) for communication between ACS controllers.
If we try not to use alarmingly importunate definitions in the press such as “IP revolution, breakthrough, etc.”, then in fact at the moment in the market of TSB and ACS in particular there is an intensive development of a new interface for communication between functional modules of the system, the advantage of which lies primarily in its industrial standardization and global prevalence. Manufacturers of ACS who are now focusing their developments on the network protocol constantly have access to improvements and new technologies that appear with the development of network standards of the IT industry, which ultimately gives them an advantage when considering the tasks of integration with other information systems at the facility or, say, convergence with the user authentication system for access to the information resources of the facility. There is another important aspect — savings on system installation. When ACS elements work with each other on an existing network at the facility, there is no need to lay numerous additional communications to ensure the functioning of the system as a single whole. If we are talking about a territorially distributed system or replacing an existing ACS at a large facility with a new one, then this “mathematics” will manifest itself especially clearly.
Let me note once again that at the moment we are talking specifically about the connection between the ACS controllers, and not the connection “controller – system server”. And it is here that the standard implementation of Ethernet (TCP/IP) based on the Linux OS in the controllers gives an advantage in organizing this interaction. The main idea is to organize a geographically distributed access control system using a network protocol to ensure, for example, the “global antipassback” mode in the entire system or to ensure a response to the triggering of a sensor “accountable” to one controller on an actuator controlled by another controller in the network. In this case, the entire process should occur regardless of the availability of the system server in the network at the moment. From the point of view of the setting for access control itself, the task is absolutely not new. The point is only that at the moment it is considered through the prism of using Ethernet (TCP/IP) networks as an interface.
The use of certain standard devices (hardware gateways) to adapt previously developed ACS controllers to work in a network, for example, by installing Lantronix modules on them to implement a virtual COM port via Ethernet, entails a number of limitations in the interaction of devices over the network and is not suitable for creating full-fledged “peer-to-peer” peer-to-peer communications between system controllers. At the same time, it is the presence of a fully implemented Ethernet protocol in Nedap AEOS ACS controllers that allows controllers to communicate directly with each other, and not through a server, while implementing a minimal network load at the facility. The presence of “peer-to-peer” communications between controllers also allows you to create and load full-fledged “virtual scenarios” into controllers in advance — complex reactions of the system, a group of controllers, when certain threats from the outside appear. In previous generation systems, this problem was usually solved by “upper” level software by implementing a certain apparatus of system reactions launched on the ACS server.
An absolute advantage in setting up these and other modes of interaction between controllers is the Availability of a web interface built into the controllers.
Which allows you to organize any workstation using the «thin client» technology. That is, to work with the system, it is enough to simply launch a web browser, for example, IE.
Thus, to deploy a workstation, it is enough to launch a web browser and, in accordance with your rights, access the server. That is, there is no need to install special software.
A number of manufacturers are already actively using the built-in web interface to manage and monitor their autonomous controllers.
In the Nedap AEOS system, the web interface operates on the network as a separate application, which allows you to use its advantages most widely and fully.
There are no problems with software updates. The update occurs simultaneously on all machines in the network, including remote offices/branches. In turn, this allows not to increase personnel, since all processes important for the system operation are controlled and managed from the center. Very important in the case of geographically dispersed objects. Users do not have problems with database desynchronization or incorrect entries in the database.
The hardware requirements for computers on which workstations will be deployed are significantly reduced. The network load is reduced several times, since only the server's work results are transmitted over the network, and not an array of data.
The problem of accessing the computer's internal resources is easily solved, all critical processes are blocked by standard Windows tools. (Currently, in a number of systems, even to launch an operator's workstation, administrator rights are required).
Protection of information transmitted over the network.
The main argument for skeptics when discussing the issues of integrating existing network standards into ACS equipment is the opinion about the insufficient security of TCP/IP connections, as well as about the problems that arise when information packets pass through various gateways and routers separating subnets. One of the solutions to this issue is to organize a VPN connection (Virtual Private Network) using the SSL protocol (Secure Socket Layer) between network controllers and the system server. VPN in combination with SSL is currently considered the most secure method for transmitting data in networks.
Of course, this requires the ACS manufacturer to implement VPN in the controller software, for which, again, options on the Linux platform look more advantageous.
In addition, to protect access to information on the controller, it is possible to use existing and proven solutions on the IT market. For example, in Nedap AEOS controllers, in addition to the implemented VPN/SSL technology, a built-in SAM module is used to protect access to the controller. The SAM module (Security Account Manager) is an administrator of credentials in the security system, that is, a subsystem that maintains a database of user accounts containing information about user privilege levels, passwords, etc. The presence of a SAM module prevents unauthorized users from accessing the controller. The SAM module can be supplied with keys that users can use at their own discretion.
Operation in PoE mode.
Of course, the presence of the PoE mode in IP ACS controllers, unlike, say, IP cameras, now looks more like a marketing ploy than a serious technical innovation. In fact, when installing such controllers at a site, you cannot in good conscience tell the Customer that you just need to “run a network” to the controlled door. The fact is that ACS controllers, unlike the same IP cameras, need to control peripheral devices (readers and actuators), and due to existing PoE standards, the output power of ACS controllers operating in this mode does not allow them to supply power to, say, long-range readers and, even more so, to electromechanical or electromotor locks. On the other hand, the total output of the AEOS AP6003 controller from Nedap is already divided into 200 mA for connecting an external reader and 500 mA for controlling the lock at the same 12 VDC. These characteristics are quite sufficient to control a door with a short-range RFID reader and supply control voltage to an electric lock or latch. On the other hand, from the point of view of correct installation of the access system, in any case, the power supply of the lock should be carried out independently of the power supply of the controller and reader in order to avoid possible voltage surges in the network supplying sensitive electronics. Further development of PoE standards, in my opinion, will expand the possibilities of using this technology in ACS and will lead to the emergence of new interesting developments in this area.
Multi-format readers and controllers.
By now, it can be safely said that a separate segment of the security systems market associated with the replacement and modernization of previously installed equipment at customer sites has been formed in Russia for quite some time. And although the ACS market in Russia is somewhat younger than the same video surveillance market and began in the mid-90s of the last century, and immediately with RFID technology (which greatly surprised representatives of Western countries who came to Russia at that time), the field for activity in this “secondary” market is now quite extensive. Requirements for replacing an existing ACS can be put forward by the customer both based on existing government regulations (for example, periodic replacement of TSB equipment in the structures of the Central Bank of the Russian Federation), and for objective reasons of moral and technical obsolescence of the existing system. In most cases, the Customer puts forward at least one, but very strict requirement: the employee passes must remain the same. Indeed, often the cost of replacing cards for thousands of personnel of a large industrial enterprise or a company with a multi-branch structure more than covers the cost of replacing all ACS equipment at the site. In addition to the purely technical issue of replacing one set of identifiers with another, there is a real organizational “headache” for security service employees associated with the physical confiscation of all old passes from employees and the planned distribution of new ones.
Naturally, for the world's leading manufacturers of access control systems, this problem has not arisen yesterday, and at the moment the market offers two main options for solving the issue of preserving (or smoothly replacing) user passes when replacing the customer's existing system.
Most modern ACS have different types of interface modules or universal devices for connecting readers with different common types of interfaces. Most often, we are talking about Wiegand and Data&Clock interfaces with the possible addition of a specific internal interface of a particular manufacturer. In this case, the ability to simultaneously operate readers of different types in the system is considered “good form”.
Another solution to the problem of storing passes is the use of multi-format readers, which usually allow reading, in addition to cards of the “native” manufacturer format, another 1?2 types of identifiers common on the market.
Nedap AEOS interface modules for third-party readers of the AP1003/6003/4X03 series, after preliminary configuration, are capable of supporting the operation of almost all readers existing on the market. In addition to readers with Wiegand and Data&Clock interfaces, devices with RS232, RS485, Omron and MagStripe interfaces can be connected to them. The library of “behavioural” components for these modules (embedded software) contains more than eighty (!) types of different formats for readers with the specified interfaces.