Amberteq

The integrated security system consists of two major parts:

The idea behind an integrated security system was to develop a system, which will operate and control security systems from different vendors and manufacturers.

In real life, each object, building, or plant has a lot of different systems from different vendors. Sometimes different systems are installed or updated at different times, some of them can be obsolete and replaced by new ones or even combined with other systems. For example, one object could have 2 different access control systems, installed in different buildings of one complex or even on different floors, different alarm systems, installed in different places of the building (for example, the second system could be added after some reconstruction, because the first one is not available for purchase for different reasons), different fire alarm systems, different video surveillance systems, structure/building life support system, etc.

Each of these systems, mentioned above has its own custom software, custom hardware, user interface, operation principles and so on. Sometimes it's even necessary to have separated computers or PCs for each of the systems. Each of these systems is excellent for reaching its specific goals.

Sometimes one vendor can cover multiple areas, for example, the access control system also can have a burglar alarm subsystem, or a video surveillance system can have some minimal functionality for organizing access control. But in case, if you want to take the best from each system - you will need to combine different systems.

If we combine different security systems on one object - we have a question - how to operate all these systems efficiently with minimal human resources, which also can require the involvement of additional human resources. It's impossible to have one operator or security officer for each computer, especially if we need to organize 24/7 monitoring.

For solving all these challenges we had to use integrated security systems which would integrate separated security systems into one ecosystem. As it was mentioned above - we had two levels of integrations - a software level and a hardware level.

On the software level, we had to ensure a connection with each standalone security system using the system "language" (to "speak" with the security system on its own language) and then convert all inbound and outbound data flows to the integrated security system unified "language" (protocol, interface and so forth).

Different security systems have different integration entry points. Sometimes we can use the described API, sometimes a software development platform-specific SDK, sometimes we can connect directly to the system's controller via UART using the described protocol. Different systems have different communication interfaces. There can be DLL calls, shared memory interaction, sockets interaction, direct UART (RS-232 or RS-484) or USB communication, etc. For each of the necessary systems, our company developed a high-level driver with a generic skeleton but with the custom interaction implementation. Even today , when we need to build connections with new hardware of an integrated security system or a security system subsystem, we need to develop a new "driver".

Not all systems can be integrated on the software level. Sometimes security systems can allow integrations only on the firmware and hardware levels, when you can integrate one system with another using single wires or relays, or something more complicated - for example, a common RS-484 system bus.

In our case, we needed to have custom-developed hardware, which would solve necessary tasks and then communicate with our high-level software, i.e. our "driver".

Together with our customer (the company has its own strong hardware and firmware development team) we developed a hardware platform, which can accept custom-developed firmware for implementation of integration with a standalone security system and communicate with our high-level driver using our protocol. A hardware platform is similar to some "box" with different interfaces (LAN, RS-232, RS-484, relays, contacts, CPU, memory, etc.) for interaction with different security system devices. By default, the "box" can do nothing, but depending on the actual security system we can upload necessary custom-developed firmware and include it in one network with this system.

Software- and Hardware-level integrations are only a basis, a so-called ground floor of each integrated security system. After we collect some signal information from the low level, we have to process this information and send it to the next levels. Before sending info to the next level - we have to organize networks and our high-level drivers correctly. Sometimes they can have their own hierarchy, can be combined in one network and located on different PCs and concentrators.

As for sending the information to higher levels, there can be different approaches. For example, we can write information directly to a DB or send it to some central processing units.

In each case, we used a corresponding approach. We developed different information "highways" for different types of data packets. Some information can be written directly to a DB, some information can be sent to the cache subsystem, some information can be aggregated and stored in temporary data storages and some information can be sent directly to operators’ workplaces. All these operations and decision making processes are carried out by our Integrated Security System Central Processing Units (ISSCP).

We always should remember that different information requires different reactions. This is why we developed strategy definition and strategy execution modules, where we can define what the integrated security system should do depending on the signal that it receives from any particular device.

Of course, this is a very simplified explanation, in real life strategies or behaviors can be much more complicated, for example, “to turn on camera A to monitor B and to turn on a sound alarm on relay C for controller D if video detector E gets a signal from camera F (for example, a cashier puts a white list of paper in case of emergency to the left top corner of her working table or performs another action that can be not seen by a robber) and we have a movement detection signal from alarm sensor G during the last H seconds and only on working days (not including day offs, holidays and weekends) and only for working hours of cashier J. We can also generate an alarm message for a security system officer with text K with color L and show alarm dialog M, then switch his monitoring software to plan N and highlight room area O with background P and color Q. Looks crazy? - Yes, but this is what we implemented and, yes, there are even more interesting cases.

All mentioned above is just a part of the logic. We also had to generate a new logical message which is equal to a list of signals and behaviors, to write a message to a DB, to specify and assign a message importance level, to specify a notification level and to notify subscribers using the specified notification ways, for example, to perform an automatic phone call and to send an SMS to a head of the security system, to send an SMS to a head of the department, where the incident happened and even notify the bank's VP (if we are talking about a bank).

Any integrated security system has a lot of modules and subsystems. In this case study, we had a goal to share our experience, to explain how we approached our tasks and what types of solutions we can offer to you. We didn't have a goal to explain the functionality of security system officer workplaces, the way they monitor the situation, prepare reports or analyze information, how their chiefs control them, how they use reports, how and who administers the system. We believe that to answer each of these questions we can prepare separate case studies.