ACS: access via Ethernet.
Everyone talks and writes about the IP revolution in access control systems (ACS). What is it in practice?
Why Ethernet?
Let's start with the fact that this is not a revolution, but rather an evolution. The process has been going on for several years, but to this day the share of ACS controllers with an Ethernet interface is not that large on the market. At least to this day they are not dominant.
The very desire to use Ethernet networks to combine ACS controllers into a single system has well-founded economic aspects, namely: the widespread implementation of network technologies. Perhaps, today it is very difficult to find an enterprise or office that is not entangled in computer networks. Moreover, geographically distributed enterprises also often have dedicated network communications for connecting the head office and numerous branches. Thus, if computer networks are used for all types of communications between business entities, then why not use them to connect ACS controllers with the rest of the system? After all, the cables are already laid, and the addition to traffic from the ACS is simply insignificant.
Ethernet solutions on the hardware (controller) side have become cost-effective. Today, it is possible to add new functionality to a traditional access system controller in terms of the element base for only $10. Naturally, the software implementation of the TCP/IP stack in hardware will also cost something, but this is a one-time expense, and if you buy a ready-made stack from a company specializing in this for its docking with the main software (SW) of the controllers, then this will cost the company — the equipment manufacturer from 2 to 5 thousand dollars. With normal replication of equipment, the costs will pay off faster than if you develop network-level software yourself.
Thus, the migration of access systems in this direction is quite understandable, and the slowness of the process is explained not only and not so much by the need for new development, but by the conservatism of the security industry, and also by the fear that a new “hole” will appear through the common network, increasing vulnerability both from intruders and from various kinds of random failures in the operation of a generally “foreign” network.
Solutions
How can you save on wires and join the general «web»? There are several ways. The simplest way, which advanced installers tried to use in practice several years ago, is to use hardware gateways that allow you to implement a virtual COM port via Ethernet. Such devices have been manufactured for quite a long time by various companies, in particular, for industrial automation systems. The most effective solution can be considered a device called X-Port from Lantronix (Figure 1). This device is completely made in the body of an Ethernet socket — a connector installed on the printed circuit board of the target device. There are also many external devices that look like standard network switches, which can be connected between the Ethernet cable and the access system controller. In the literature, all devices of this class are most often called asynchronous servers. Figure 2 shows a diagram of connecting a standard ACS controller through such a server.
Figure 1. Ethernet to COM port converter.
Why hasn't this simple (and very budget) solution become widespread? Because it doesn't always work.
Figure 2. Connection via an asynchronous server.
Classic ACS controllers are connected via the RS-485 interface, with up to several dozen per interface line. By its nature, RS-485 is a master-slave interface, where the PC polls the controllers connected to the line in turn. A response is expected for each request, and if there is none for some reason, the controller is considered faulty. The response timeout may be too long to ensure adequate system response speed in the presence of an unresponsive controller. Typically, the timeout does not exceed twice the duration of the controller's response, which is approximately 50-100 milliseconds. If there is no response longer, the controller is faulty.
At the same time, delays of up to several tens of milliseconds in the chain computer – virtual port driver – TCP/IP stack – Ethernet network – router (switch) – asynchronous server – controller can occur quite regularly, which leads to the actual inoperability of the solution under consideration.
Thus, it is difficult to obtain a working system without reworking the software of the controller itself. A qualified solution looks different: an Ethernet controller (analogous to a network card in a PC) is installed in the controller, with which the microprocessor of the ACS controller directly interacts. Naturally, the controller software in terms of exchange with the PC changes dramatically. Thus, an ACS with Ethernet is a fairly complex new development, and the manufacturing company must be motivated by the market situation.
Ethernet Protocols
So, we have the ability to connect ACS controllers to a PC running the access system software via a shared (or maybe dedicated) Ethernet network. What problems can we expect along the way? These problems usually arise when working in a shared network administered by an IT department system administrator who has his own views (and, as a rule, not unfounded) on how a corporate network should work, what protocols and ports to allow or prohibit in different network segments. Let's first see to what extent an ACS can use certain network protocols. There aren't that many of them — UDP, TCP/IP and HTTP.
UDP
The fastest and least expensive protocol. Allows exchanging packets no larger than one Ethernet frame (approximately 1500 bytes). But this is more than enough for us — in the ACS, the controller rarely exchanges packets larger than 100 bytes with the PC. Thus, due to its speed and simplicity, UDP is the first candidate for use in a real-time system. It is no coincidence that many network protocols of industrial automation systems operate on it. The disadvantage of UDP — the lack of guaranteed message delivery — is easily overcome by the same methods as when working with RS-485: acknowledgement, i.e. transmission of confirmation of receipt of each packet.
TCP/IP
This protocol provides guaranteed delivery, it can «cut» large data packets on the transmitting side and «glue» them together on the receiving side, but we don't really need that. But it is slower and much more expensive to implement in software. Its only advantage is that it most often goes through corporate switches and routers by default.
HTTP
This is the slowest of the protocols, it is «built on» TCP/IP and is used as the main one in the WEB, i.e. it is with its help that we receive information from the Internet. It follows from this that it is used practically on a global scale, which is its definite advantage. But in real-time systems, its use is practically impossible due to its slowness.
What is better?
From a brief overview it is obvious that for real-time systems, such as access control systems, it is preferable to use the UDP protocol. If you have a very simple network, then this will not cause any problems at all, everything will work fine, and at an excellent speed. If the network is a little more complicated, and the system administrator has «closed» unnecessary ports and protocols, the system will not work until the specified restrictions aimed at IT security are lifted. In the same way, the Internet will not work if you close packets addressed to port number 80 for passage.
If the network consists of several subnets, then it is necessary to ensure the passage of UDP packets through routers separating the subnets. So, if the entire network to which the ACS components are connected is under your control, you cannot find anything better than UDP.
If the network is not fully controlled, then in some cases it is possible that TCP/IP will pass where UDP will be cut off, although no one can guarantee this. Using HTTP, as already mentioned above, is simply impossible for real-time systems. However, there is a way out — VPN.
VPN Trojan Horse
VPN – Virtual Private Network, or in Russian, virtual private network. This is a good invention that allows you to transfer any data via public networks using any standard protocols. If you were told that you can’t use a blue pipe in your garden, but you really want to, you can take a permitted red pipe of a slightly larger diameter and stick your blue pipe into it. That’s how VPN works, figuratively speaking. And since this is a global standard, there will be practically no problems when organizing communication in any networks – at least, these problems are always solvable.
HTTP
So, we (or rather, the harsh reality) have rejected the HTTP protocol as a means of communication for real-time systems. At the same time, it is on the basis of this protocol that new and quite interesting functionality in ACS is already being implemented. Firstly, there are tasks that do not require a response within a fraction of a second. Such tasks, for example, include the formation and viewing of reports on the operation of the system (visit control, work time accounting, etc.). And since the protocol ensures passability through any networks on a global scale, we get the opportunity to view reports from anywhere on the globe. The only thing that is required for this is to «re-equip» the access system software with a small WEB server, which will provide communication between the system event database and the client on the other side of the World Wide Web.
And another progressive solution has already been implemented based on the HTTP protocol: these are autonomous controllers with a WEB interface. Such a controller can be obtained if a regular autonomous controller is supplemented with an Ethernet controller in hardware and a WEB server in software. In this case, we get the ability to control the controller, change its configuration and even view event reports using a standard WEB browser, which is always available on any modern PC. In other words, we get an autonomous controller with PC control without installing any additional software on the PC.
The only problem is that without additional measures we will not be able to combine such controllers into a single network, i.e. ensure the exchange of information between controllers and centralized management and monitoring. To solve this problem, the controller software must be supplemented with a number of other functions, which, however, is not an impossible task.
And if you get a dedicated IP address for the organization, then access to such a controller will be possible again from anywhere in the world. Of course, the question of the security of such a solution from intruders arises, but this can also be solved — you can use the same VPN, which we talked about a little higher. Of course, implementing a VPN in a controller is not an easy task and is very expensive, but the protection of the communication channel outside the organization by means of VPN can be taken over, for example, by a computer dedicated to these purposes.
This is what solutions look like that allow you to extract some benefit from the presence of Ethernet networks in your organization, city, country…