Integrated Security System Development with Real-t

Integrated Security System Development with Real-time Hardware Monitoring Capabilities of Fire Alarm, Burglar Alarm, Access Control Systems from Different Vendors

CORE MODULES

  • Unified internal protocol & data interchange between systems from different security system vendors, development of custom API drivers for each security system
  • Central workplace for a security system officer for monitoring the situation in the whole building on one screen, displaying visual information from all sensors
  • Custom reporting, system failover and backup

KEY FACTS

  • 50 000+ logical security system objects/entities on real installations
  • Successful interaction between 2 and more standalone security systems
  • 1 000 000+ sensor transactions per day

Softacom developed a unified integrated security system for operating, administration and control of security systems from different vendors and manufacturers. Different vendors - one informational space

Description

Our customer is a global integrator of security systems. The customer provides turnkey solutions for any type of security systems and clients, from an atomic station to a global international bank.

The client made a decision to develop its own high-level integrated security system, which would operate all standalone security subsystems as a whole. Our client is a partner of dozens of well-known security system manufacturers and knows all their systems very well. For each new client or object, the company tries to suggest the best solutions and take the best from each security system. Sometimes it's necessary to integrate security systems with each other, even if these systems don’t have ready-to-use SDKs and APIs.

The client also has its own high-level high skilled software development team. But for the development of brand-new software, it was decided to involve the dedicated offshore team and to use their own team for current and future support. The key requirement for the new team was proven expertise in software development in the security system technical domain.

Based on the customer's experience of cooperation with our company in the past, the customer chose us as their strategic partner for this new project.

The client already had their own developments of some parts of integrated security systems, the work on them started in the early 90s. We had a goal to merge the company’s experience, their vision and their developments together with modern and cutting-end technologies and frameworks.

Solution

The integrated security system consists of two major parts:

  • Custom software part;
  • Custom hardware part;

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 heed 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.

Want to know more about custom integration of integrated security system and burglar alarm security system?
Contact us. We’ll help

Software-level integration

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".

Hardware-level integration

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.

Operation & Administration

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 e 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 correspondent 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) the 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.

Methodology

Project realization included multiple stages:

  • Business analysis, including research of customer's existing solutions and developments, collection and specification of new requirements;
  • Standalone security systems (systems which should be integrated to our integrated security system) research, work with vendors, partnership building, receiving SDKs and guides, sometimes even ordering integration support;
  • Research & Development (R&D);
  • Development phase on a Continuous Delivery basis (when it is be possible, QA);

At each stage, we worked using the Agile Methodology with all necessary Scrum principles. We had daily meetings for separated teams, sprint reviews, sprint planning meetings, sprint retrospectives. Some subprojects with strict requirements were implemented using a fixed-price business model.

Technologies

For this project, we used a rich stack of different technologies and frameworks.

  • For high-level "drivers", where performance plays a crucial role, we used Delphi and C++ Builder technologies to build Windows native applications with the best processing and operational characteristics;
  • At the UI level, we had a combination of desktop Delphi-developed and .NET-developed modules built with UI libraries used as DevExpress;
  • The data storage level has generic connectors and can use a particular DB system, available for a specific client and applied for an expected load level. We introduced the support of Firebird, Ms SQL Server and Oracle databases;

Summary

This project was a real challenge for us and for our customer. It's impossible to develop a similar system without a good budget, faith in success, patience and, of course, huge experience in the security systems domain..

We have managed to conduct this project successfully thanks to many factors, among them we can name the experienced teams from both sides (our team and the team of our client), deep understanding if business peculiarities from the client's side and, what is extremely important - the possibility to apply our R&D and intermediate developments to real-life cases for existing clients to solve particular tasks. We were not developing the system in the vacuum environment for 5 years. Our client has a stable business and we could integrate our solutions step by step.

RELATED PROJECT

FULL-CYCLE ACCESS CONTROL SYSTEM DEVELOPMENT

Softacom helped an access control system manufacturer to develop a .NET Windows application for configuration, administration and monitoring of an access security system, as well as helped to build communication between hardware devices and desktop software via UART and USB interfaces.