Content on this page requires a newer version of Adobe Flash Player.

Get Adobe Flash player

Security Integration or Mystification?

Reported April 2009

By Brian Kelly, Managing Director of Bold Communications

The term ‘integrated system’ is used to describe such a variety of different security applications as to be evocative rather than descriptive.  There is no law that says you cannot connect two security systems together and call them integrated.  In the integrated security environment, the definition is heading towards the position of having two or more applications in use together, one of which incorporates an alarm element and where there are common controls or services.               

Operational objectives, supported by the availability of new technology which makes the whole exercise possible, in particular, IP networks and the .NET development platform, are driving interest in and demand for this type of solution.  Organisations like the Open Network Video Interface Forum (ONVIF) and Physical Security Interoperability Alliance (PSIA) are seeking to develop common technical standards for CCTV interoperability which may be likened in some ways to the industry standard signalling protocols which prevail in the alarm industry.  If these moves prove successful, it will make life easier for developers and open up the options for end-users.          

Alarm management is distinct from remote video surveillance as more rules apply.  Where Police and Insurance company approval is sought, alarm systems, including the signalling technology and at the alarm receiving centre must comply with the relevant standards.  Discussions are taking place in Europe to agree technical specifications for system integration, with one of the key objectives being to ensure that individual standards are maintained when they become part of an integrated solution.  This is where the subject becomes complicated because a system may contain non-security elements, such as controlling heating, lighting or message broadcasting.  In this case, the security element must conform to the relevant standards and operation of the non-security parts should have no negative impact.        

At one end of the extreme, integration is pitched at the component level, meaning that all devices will signal by the same, usually IP, communications interface, whether it is an alarm panel, CCTV camera or access controller.  This is a tidy answer, particularly for the supplier as the end user will be locked in to the delivered solution.  At the operational level, my view is that integration means communicating with and managing centrally a diverse range of systems by means of multiple receivers, with one customer database and one standard operator interface (although of course there may be many operators). 

It should not merely be an extension of the security guards eyes or, even less useful, present an unmanageable number of camera views which cannot realistically be viewed effectively.  The integration must add value by doing something intelligent with the information received, for example, by automatically escalating a response.        The system design should not represent a snapshot of security technology as it appears to a developer on any particular day.  The starting point should be – what is already out there that we need to work with and what do we need to do to make sure we support new technology as it approaches – a hybrid system.  Many current management solutions do not address the issue of legacy, analogue-based systems of which there are many in use. 

Lastly, we should not forget the control room operator who has to make sense of all this information, or at least have an automation system which can make sense of it for him.  Although many response actions and activity reports can be system automated, for critical, real time alarm events a human element will usually be involved and they should be given the best possible chance of making the best possible decision based on the information in front of them.     

 

Originally Published in Risk Manager, Spring 2009, Volume 10, Issue 1

Privacy Policy  |  Terms and Conditions  |  Site Map