[breadcrumb]
Custom Integration of Integrated Security System and Burglar Alarm Security System
CORE MODULES
- LAN high-level "driver"
- Custom protocol encryption, decryption and validation module
- HFailover detection and watchdog module
KEY FACTS
- 99.999% module uptime requirements
- Strict and conservative client
- Custom integration with police service departments
Amberteq helped a security system integration company to integrate their client's (a local representative office of the international financial company) existing security system with an alarm security system of a new type
Duration
4+ Years
Efforts
100+ Person-months
01.
Description
In each country or region (including the European Union) each local market has its own list of security systems that can be used for objects, companies and buildings of high importance. All security systems should be certified. Only after the system is by the national or regional certification authority, it can be used for the existing and new objects.
Our customer asked us to help them to integrate their system with the first-time certified burglar alarm security system. We had to integrate the existing integrated security system used by the client's office security service with a brand-new system.
We faced two serious issues :
- The vendor didn't have external integration for its security system at all;
- We had a requirement to monitor events and signals that at the same time had to be sent to the police department via "closed" communication channels;
- IOur client (the organization that was going to use this brandnew integration) is a bureaucratic organization with multiple levels of approvement of any technical and technological solutions including necessary internal certifications;
02.
Solution
CAs it was described above, at the beginning of our work we had to build the solution for integration (proposed technical solution - API, SDK, direct connection, etc.). The vendor didn't have any integration experience in the past and they asked us to suggest and describe the best practices.
Our business analysis team considered the vendor's solution, data interchange architecture and data interaction principles between native software and hardware and suggested an optimal solution for the implementation of version #1, which wouldn’t take years. Moreover, the vendor had to get the system certified again after the integration because the core of their system was supposed to be changed.
After the solution was approved by both parties (our team and the vendor's team), the vendor's team started API implementation on their side.
At the same time, our team started two other activities:
- Implementation of a driver application;
- Discussion with the police security system department (together with the vendor) of how the client's security system would receive alarm signals simultaneously with the police security office, which signal would have higher priority and how to solve collisions;
During the driver application implementation, we could implement the protocol only using a prepared project of the protocol without real hardware (theoretically), because the vendor was working on the implementation of the protocol on their side. For internal use, we developed an emulation of the hardware and vendor's software part for the testing. Actually, later , we had some problems with the communication to real software, but we had a budget for its stabilization and we reserved the time for that as well.
The vendor's existing software also has strong encryption and signal/transaction confirmation inside their internal ecosystem. e implemented the same level of protection and complexity for external integration. It means that our driver which is connected to the vendor's system uses the same level of encryption/decryption and supports necessary transactions handshaking.
At the business analysis stage together with the vendor, we prepared a list of available for events, equipment/devices states and commands. We mapped available events and commands to the API. In this case, our integrated security system can monitor and control the vendor's alarm security system almost with the same functionality as the vendor's native software. The major difference is that the integrated security system cannot program/administrate alarm security system, i.e. configure devices, set up properties, save the program in the controllers’ memory.
03.
Methodology
Project realization consisted of multiple stages:
- Business analysis, including requirements collection, new requirements specification, previous experience analysis, modeling and design, mockups creation;
- Implementation of necessary hardware emulation software;
- Research & Development (R&D), including checking of data communication techniques for allowed "closed" and secured data channels;
- Development phase (Waterfall methodology);
- QA;
- RDeployment;
At each stage , we worked using Waterfall Methodology with strict planning.
04.
Technologies
For the project implementation, we used an integrated security system high-level "driver" application template. To ensure the best performance, as an application template we’ve chosen a Windows native application, based on Delphi-related technologies. It works without any additional frameworks and doesn’t need any execution environments like .NET Framework. We cannot apply high recommendations and requirements for the end-user machines, and we even cannot apply strict recommendations for necessary prerequisites.
05.
Summary
The delivered integration was successfully applied to the existing system. Nowadays the solution has dozens of active installations for different types of organizations.
Our customer - a security system integrator - reached their goal. Now they have a newly certified burglar security system in their portfolio and can offer their existing and potential customers to integrate this burglar security system to their integrated security systems.