SKUD: If the mountain won't come to Mohammed.

ACS: If the mountain does not go to Mohammed.

Problems of integrating ACS into building automation systems

Preamble
A meticulous reader may immediately ask: why the problems of integrating ACS and not security systems? After all, ACS is an integral part of an integrated security system, and we should talk about integrating security systems with what is often called a «smart home», or in the language of specialists — home automation. This article is partly devoted to explaining this contradiction, and if, looking ahead, we try to draw analogies, then history may repeat itself…

… and things are still there
Much has been said in recent years about the problems of integrating technical means of life support for buildings, and if there is some progress in terms of integrating security subsystems, then in the issue of more comprehensive integration with other subsystems (lighting, air conditioning, etc.), problems really exist, and progress is much less. Trying to analyze the reasons for this state of affairs, one cannot help but mention departmental barriers. Until now, at the absolute majority of facilities, security services are responsible for the security system as a whole and the access subsystem in particular, and the building operation service is responsible for everything related to the automation of the building, which includes ventilation, air conditioning, lighting, heating, etc. The latter, as a rule, has considerable powers, is more numerous, and, most importantly, is absolutely not motivated to find short and effective ways of integration with technical security systems. The security service, in turn, in an effort to maximally close the work of technical security equipment (TSE), often does not want to hear about integration with other life support systems of the building.Such departmental conflicts are by no means a purely Russian prerogative. Approximately the same picture is observed abroad. And this is one of the stumbling blocks. They have been talking and writing about this almost continuously for a number of years, but to this day this problem has not been fully resolved.

The second problem is more of a historical nature. It is related to the fact that the integration solutions themselves were developed by different companies using fundamentally different approaches. And today it is very difficult to connect these rather complex systems, made on a heterogeneous basis.
If we look at the lower level of building automation systems to understand what security systems are to be integrated with, we will see a variety of so-called «field buses». These are LONWORKS, CAN, Profibus, Modbus EIB and some others. The standards corresponding to these buses extend upward to the level of so-called application profiles, which strictly standardize the network interaction of devices that are simple in logic and operating principles — switches, relays, sensors and other elements that ultimately implement an industrial automation system or building automation. Almost all standards profess the ideology of distributed intelligence, when the central node (for example, a PC-based system server) mainly serves as a means of programming and collecting the results of the system's operation for subsequent analysis, and sometimes for making some control decisions. In this architecture, all devices are fundamentally equal, accordingly, there are rules by which they communicate with each other, there are rules for configuring and addressing these devices.For example, a switch is a source of a signal in such a network, and a small board or box, which is a receiver, can be installed next to a light bulb. Such a receiver can independently receive commands from the network, which come from the switch, from the light sensor, or from the alarm system. That is, in all cases, a light bulb is a light bulb, it has an address in the system, it is able to receive commands. And someone else is able to issue these commands. There are also combined devices that can receive something, issue something, and in between, also perform some calculations. For example, there are some blocks that are a connecting element between the same light bulb and a photo sensor. They can be located, for example, in the board that services the photo sensor, being both a receiver and a transmitter. It receives information from the photo sensor directly or via the network, and transmits it to the light bulb. All this is based on strict standardization, all these protocols for the interconnection of control sources and actuators have been well developed for a long time.

The root of the problem
Why, then, are there still problems even technically in terms of integration, and how is ACS so different from the other automation systems under consideration? After all, we can imagine a reader that can send a code of a read card to the network, and a lock equipped with a board that can receive a signal over the network and open the lock. There is a hypothesis that the reason is in people. Not in those who create systems or operate them, sitting at monitors, but in those who walk through the doors. ACS users are an integral element of the system with a huge variety of specific properties and rules for processing their actions. It seems to me that this is what gives ACS systems the multidimensionality that is lacking in simple network topologies of automation systems. And it is the implementation of functionality associated with people as elements of the system that causes problems when trying to fit everything into a simple «sensor — actuator» scheme.If we return to the current situation, it should be noted that there have certainly been attempts to cross security and automation systems. For example, about four years ago, CAN Open developed profile 416 for alarm and door control devices, which went a little deeper than competing standards: it establishes the interaction of devices that are components of security systems — security alarm sensors, fire sensors, electric locks. Moreover, this profile describes the procedures for configuring and setting them up. Thus, there is already a platform in the rank of a standard for almost complete integration. The word «almost» is used because, again, people as elements of the system are not yet taken into account even by this, in our opinion, advanced standard.

ACS and SCADA
Any ACS, like any automation system, is also control software with a clearly expressed application specificity. The so-called SCADA systems developed for automation systems (this is the upper level, which is an analogue of security system software) are good only for simple devices. The SCADA system can be used for security and fire alarm functions, but attempts to implement the full functionality of the ACS by its means lead to the fact that it is necessary to “adapt” almost all the software of the access systems to the appearance and internal structure of the SCADA — it is impossible to implement the required functionality using built-in SCADA tools. The access system is the most intelligent of all security systems, the variety of its configuration options and operating algorithms is so wide that the problem of standardizing all these things will not be solved very soon. In order for all this to become a standard, at least the key players of this market and equipment manufacturers must agree. Therefore, if we talk now about the integration of access into the building's life support system, we can state only partial real integration — the use of actuators (buttons, locks, sensors) operating within the lower transport level of the network. But the basic functionality of the access system itself with decision-making when organizing complex algorithms for managing access points, building reports up to accounting for workers does not yet fit into any framework of standardization.
A SCADA system is a fairly mature thing, well standardized, it seems to have a fairly rich interface, the ability to design graphical objects that dynamically change under the influence of something happening in the system, that is, various animated plans. But again, its functionality and the structure of databases typical for SCADA do not cover all the needs of access systems. This is the main problem. Therefore, now, speaking about integration, we have to be content with some partial solutions. That is, the building automation system can use some actions as controls from the ACS. To do this, it is enough to program a regular relay output for some event on a standard controller from any manufacturer, use this relay as a contact sensor for the automation system. And based on this, make decisions somehow related to the actions of the access system. For example, with the factor of legal passage, illegal passage — depending on who needs what. Deeper integration is not expected in the foreseeable future.

So what next?
We have painted a sad picture, trying to explain why no one wants or can perform a full-scale integration of the entire electronic infrastructure of a modern building. And yet, this is not a dead end — after all, as the old proverb says: «If the mountain will not come to Mohammed, Mohammed will go to the mountain.» Today, a trend is already emerging for solutions that do not provide for the inclusion of an access system as a component in the building automation system, but, on the contrary, «docking» the building automation system to the access control system. This can happen very simply: a security system, especially an ACS, if we are talking about software, is today a developed system with very rich functionality, including built-in mechanisms for creating programmable reactions to any combination of events. Nowadays, any serious software is built with certain macro languages, due to which such software becomes unusually flexible, partly turning into a tool for creating software with new properties not included at the design stage. A macro language is actually a simple programming language for a system, where the functionality of the system can be set by any more or less qualified user.
An example of the application of macro languages ​​in ACS is the formation of complex checkpoints — the same gateways that are required in card issuing centers according to VISA and MasterCard requirements. These requirements are quite complex. The gateway must necessarily let through only one person at a time, identification is performed by more than one feature. But what is a gateway? This is door number one and door number two, these are sensors that ensure not only the recording of a person's presence inside the gateway, but also a more or less reliable check that the person is alone there. In our practice, there was a case of manufacturing a gateway with a weighing platform for one of the banks, when the weight of a person who presented a card is «pulled out» from the access system database and compared with the measured one, taking into account tolerances. The weight tolerance takes into account seasonal fluctuations — the weight of clothing, and, in addition, the effect of natural weight loss or weight gain for a person. Now it is quite fashionable to lose five kilograms in six months to a year. For half a year, such a change in weight is normal, but for a week it is quite unusual. The system tracks the employee's weight every day, and, accordingly, makes adjustments to the personal data of the average weight in the database. The organization of all this complex logic of the buttons, sensors, weighing platform, door sensors, infrared sensors and so on, can be solved in two ways. You can write specialized software, which, taking into account its debugging, will cost a lot of money, and it will be implemented in one, two or three copies. Not every corner of our country issues bank cards, and the implementation of such gateways is a unique, one-off job. In ten years of work, I have not seen two identical orders with repetitive requirements for the logic of the gateway. So, all this interaction can be implemented using those same built-in macro programming languages. Like Word or Excel, there is Visual Basic, which allows you to do amazing things with well-known programs — just few people use it. And it allows you to automate everything that can be automated. It is due to the built-in programming language that interacts with the environment — with the editor and with the Excel table. By analogy with this, the macro languages ​​built into the security system software allow you to implement any algorithms for interaction between any input and output actions. Almost any modern ACS controller has several additional inputs and outputs, signals from them can be interpreted, rules for processing actions can be written in the macro language depending on additional conditions (for example, on the time of day), and output actions can be generated not only to control the lock, but also additional controller outputs. If you also ensure hardware compatibility of controllers with standard field buses, the result can be even more impressive.