Software for modern access control systems.
It is known that software is the weakest point of the system. This statement is true, perhaps, for any system, and TSB here, as you understand, can in no way be an exception. Everything that works on regular PCs, especially under Windows, is definitely not reliable enough, subject to failures, freezes, errors. Therefore, it is customary in modern systems to transfer all the main functionality that ensures the operation of the system to hardware devices.
In access control and management systems, such hardware is controllers. They store personnel databases, the controller itself knows who, when and through which point (if it serves several points) to let through, it is ready to respond very quickly to any event that occurs in the system. The main task of the computer software, that is, the top-level software, is the ability to configure the system, operational monitoring, various application functions: reports, accounting of working hours. But shifting tasks related to the logic of the system to software has never been a feature of professional systems, and today even more so, because the development of technology allows you to implement any functionality on which the survivability of the system depends, based on hardware devices.
Many modern controllers work on their own operating system, usually Unix (Linux), and, in fact, are computers based on industrial PCs. Application tasks are written for them that implement the functionality of the controller's capabilities. From the point of view of the development of technology and technology, I readily admit this. From the point of view of common sense, quite natural questions arise, in my opinion. It is clear that the modern element base allows you to do almost anything. But is it possible to ensure a competitive price for such equipment? After all, it is obvious that, for example, the memory size of a controller that is to work under an operating system like Linux must be increased by orders of magnitude compared to controllers that do not use a general-purpose OS. The minimum that is required for the operation of Linux itself is a megabyte of program memory and a megabyte of RAM. Meanwhile, the most serious and multifunctional ACS controller, built on the basis of a microcontroller, requires no more than 64 KB of program memory and no more than 32 KB of RAM. And you also need to take into account that Linux, as a rule, brings all the problems of available operating systems. For example, the response time to some events may increase significantly. Agree, if the controller searches the user database not for 0.2 seconds, but for a second or more, this in no way indicates good system performance.
On the one hand, it is understandable that developers want to use an operating system like Linux, because it simplifies the process of creating the controller software itself — the operating system provides all the basic input/output functionality, a file system, Ethernet TCP/IP stacks — all of these are built-in functions of any normal operating system, including Linux. On the other hand, for real-time systems, given the flow of events, a long system response is hardly acceptable. Many customers today already have a certain opinion about how the ACS should work, and there is no need to worsen it.
Of course, you can't compare controller software and top-level software. But you need to keep in mind that these programs always work together. Only together, and they complement each other.
It is clear that the task of creating a monthly report on a computer for a company employing 50 thousand people is absolutely natural for him. Therefore, he can be directly engaged in it and not be distracted by anything. The controller has a completely different task — to ensure a lightning-fast reaction to any event that occurs. Therefore, they are built fundamentally differently.
Many of my colleagues have gone through this: transferring real-time functionality to a computer that is “big and can do everything”. And they certainly had problems, because a computer, I’m not afraid to repeat myself, is an unreliable thing. And if a security guard also installs some kind of toy on it… Therefore, the basic functionality that ensures the operability and survivability of the system should not be on the computer, but only in the controller. The basic functions of the controller are servicing everything that happens in real time. Outside of real time, there are two things: programming and monitoring. Reports, which, by and large, also relate to monitoring, but are a retrospective of events, I would single out in a separate category. These functions are very important, without them, a modern ACS is unthinkable today, but they do not determine the survivability of the system.
And all the functionality that ensures the survivability of the system should be in a closed controller. It is quite difficult to damage what is inside. The controller will work if it is disconnected from the socket, from the computer. It is clear that if you disconnect it from the sensor, it will no longer protect. But it will give an alarm signal that it has been deprived of the sensor. The controller, I repeat, is in any case the same computer with its own software, and quite complex. What can it be compared to? Perhaps, with a modern car. What motorists commonly call «brains» are, in fact, microprocessor units, each of which controls «its» system: engine, lighting, airbags, braking system, etc. At the same time, they interact with each other.
At the same time, you can't just install any microprocessor in a car. You can't write a program for it on anything, because such software won't pass tests. The requirements for the reliability and survivability of microprocessors and software in the automotive industry are extremely strict. For example, a microprocessor must be dual-core. One core actually performs the main task, for example, monitoring and controlling the brake system, and the second one carries out constant diagnostics and backs up the first one. Because the car's brakes must not fail under any circumstances.
Run a modern program through all branches of the algorithm during testing — this can take if not years, then months. In order to simplify the testing procedure, there are specialized development tools that allow you to avoid human errors as much as possible.
In security systems, the requirements are not so strict, but in the end — the same thing. The controller software failed, the door was blocked — something irreparable can happen if, for example, a fire broke out at the facility.
What is the future of systems running under Windows? I am convinced that they were, are and will be. But — only the servicing part of the system, not participating in its real life.
In fact, this has always been the case in most systems. Even in the very first systems, whose functionality was very limited. If you look at the hopelessly outdated, but still valid GOST on access control and management systems, then, say, the required volume of the event buffer is calculated by a figure that seems ridiculous today. Even children's toys do not have this now.
Thus, we emphasize once again that there is «hardware» software that controls hardware devices, and there are high-level programs designed for monitoring, programming, creating reports, integrating with other systems not related to security, for example 1C.
If we talk about computer software, we should remember that the first security systems were not integrated. There was a pure ACS, there was a security system, CCTV. Each of them is an absolutely closed system. Today, for example, you probably won’t find a “pure” access control and management system. Any normal manufacturer has an ACS integrated with CCTV, OPS.
In this regard, approaches to building top-level software have changed quite seriously. The fact is that producing the entire range of equipment for one company is a very expensive matter. Therefore, software packages are created that allow expanding the capabilities of systems and connecting equipment from third-party manufacturers. And this can safely be called a trend. The most striking example is the SCADA system.
It is worth noting that there are already companies on the Russian TSB market that do nothing but integrate software. Of course, it is not easy for them to work, since there is still no progress with open standards, as they say, but they negotiate with manufacturers and promote their products quite successfully.
This, in my opinion, is a very promising path. We just need to solve the existing problems as quickly as possible. The problems are old, but unfortunately, they are no less urgent than they were several years ago. The main one is standardization. There is a lot of talk about this, and not only in industry publications, but in reality nothing has changed. Of course, there are objective reasons for this, for example, the insufficient development of our market segment, its excessive and not always justified closure. Again, we cannot help but take into account that the range of concepts and values in ACS is so wide, not to mention protocols, that even at first glance it is clear how much work needs to be done. And here we inevitably come across the main subjective reason — the human factor. It seems to me that people are often hindered by inertia, unwillingness to do extra work. And many, while perfectly calculating today's benefits, for some reason do not understand that the ability to choose from a large variety is a commercial advantage. A truly high-quality product will not stop being purchased, even if the customer has the opportunity to replace individual components that are not suitable for him with something else. The ability to choose a complete set for your system or, conversely, to produce a complete set for a system of another manufacturer that will be in demand — this is absolutely profitable. For all serious players in the TSB market.