Welcome to my first blog for Info4Security. As an avid reader of the site, I intend to share the perspective of the security consultant across a number of areas and hope that you will find the content informative, interesting and even entertaining.
I intend to talk about a range of subjects that will be aimed at helping you to better understand the technology, the market in general and basic security strategy all through the eyes of a security consultant.
So what exactly is Physical Security Information Management, or PSIM?
I regularly have conversations with people from all parts of the security sector who are not clear on what PSIM is or the benefits that it can offer. I’ve heard PSIM described as ‘an integration front end’ or as ‘a Graphical User Interface to monitor a range of security systems’. While the integration of a range of physical security systems is indeed one of its functions, there’s so much more to PSIM than it simply being an integration tool.
To be frank, I think the PSIM solutions vendors have all been a little guilty of describing it in relatively technical terms (and I have myself fallen into a similar trap in days gone by).
On that basis, let’s look initially at the basics and then add some of the more technically complex areas that will hopefully enable you to differentiate between PSIM, a video management system and a graphical integration system.
Common monitoring platform for end users
Essentially, PSIM is a piece of software enabling users to view a common monitoring platform that facilitates ‘situational awareness’ at any given time.
In other words, a security operator who’s using PSIM as a security tool via which he or she is monitoring CCTV images, access control transactions, alarm event information – and (potentially) a range of other status monitoring devices – can do so from a single workstation (although probably using three or four monitors).
The Integration of a broad range of security and other systems is achieved via an IP interface along with some software that allows both systems to communicate.
The interoperability of security systems is a large subject in its own right, and one that I will return to in a future blog. It’s certainly true to say that an interface between the PSIM software and another system will require, at some level, a form of ‘code’ to be written by both parties – which is usually shared via a Software Development Kit (SDK) – or an integration device to be used.
That’s the ‘integration’ aspect, then, but – as previously inferred – system integration is far from all that the PSIM software is able to offer. Within that software there are a number of advanced processing functions are constantly analysing all of this information (ie the images, the access transactions and the alarm event activity, etc) collected from all field devices.
Commonly referred to as ‘engines’, most PSIM products use specialist processors to handle resource-hungry features such as rules, correlation, geospatial mapping and dispatch.
Let’s now look at what each ‘engine’ delivers as it really is in this area that the key differences between a true PSIM product and some other integration tools are to be found.
The rules engine: what’s it all about?
Within the rules engine it’s possible to programme complex ’cause and effect’ scenarios. By way of an example, let’s examine what happens with a basic alarm activation.
It’s possible to programme PSIM so that an alarm activation of a device in a particular area can initiate a number of pre-determined actions. That might include the display on the operator workstation or video wall of a certain selection of camera images, the locking-down of specific doors, the switching on of security lighting, closing of car park barriers, the initiation of alarm sounders and many other actions.
These pre-defined ‘rules’ are dynamically controlled and can be manually or automatically adjusted by the PSIM itself to perform a different set of actions based upon a range of factors such as the time of day, the prevailing threat level or, for instance, as a direct consequence of a combination of events.
Also achieved within the rules engine is the ‘filtering’ function. This is an important feature that can offer substantial benefits in comparison with a standard ‘Command and Control’ integration tool.
The filtering function enables continuous live assessment of all field devices. Based upon the cause and effect ‘rules’ and ‘correlation’ criteria, as well as the prevailing threat level, it prioritises and filters out device alarm activity that’s not considered important according to the systems settings.
Let’s look at an example of how ‘filtering’ can reduce the level of alarm activity that would otherwise be presented to a security Control Room operator.
Imagine that an access control system has been deployed within a large integrated security system that covers the estate of a corporate enterprise. All access-controlled doors have ‘door status’ monitoring installed and, during normal hours, the host business is experiencing a high level of ‘door held’ alarms.
For their part, the engineers have tried to assist by extending the ‘door held’ time (thereby impacting security levels), but still there are a high number of alarms being experienced.
This begins to cause problems in the Control Room as the operators cannot keep up with the volume and a backlog of alarms is building up in the event log. Fairly quickly, the security operators become desensitised to this type of alarm activity and routinely accept the alarm without any form of verification.
Once PSIM is deployed, the alternative approach would be that a single ‘door held’ alarm, without any other ‘correlated’ event, would be filtered out and not presented to the operators at all. All alarm events would be retained within the relevant systems database, but only a ‘door held’ alarm – that, for example, was held for over 90 seconds and where another alarm event occurred within a 20 m radius, when the prevailing threat level was at three or above – would be presented by the operator as a ‘situation’ for management.
This single feature can have a dramatic impact on the level of resource required within a security Control Room or offer scope to expand the services that a security operator might undertake.
Event correlation: a powerful system tool
That brings us nicely onto the correlation engine. This is a powerful system tool that allows events or alarm inputs to be ‘correlated’ or interconnected.
An example of a correlated event might be as follows… An authorised member of staff loses their access control card while out at lunch. Someone finds the card on the road outside the office and attempts to gain access to the building. They present the card to the reader at the main entrance and access is granted.
Once inside, they decide to pass through reception and go looking for a laptop that they can steal. As the individual is unaware of which doors the card is authorised to unlock, they present the card to the readers that they find as they walk into the office area.
Unbeknown to the unauthorised intruder, that individual presents the card to two doors that are not included on the user’s access rights. It’s possible to programme the correlation engine to raise an alarm and perform any number of consequential actions as described within the rules engine. This ‘correlated’ event may be programmed to present a still image of the authorised cardholder as well as live video images to aid verification.
The correlation engine isn’t something found in standard integration systems or video management systems and can offer an extremely effective method of further filtering out low-level, unwanted alarms.
Another key feature of PSIM when compared to other integration tools is the ability to pre-programme operator instructions or standard operating procedures into the system. Upon an alarm event it’s possible to present a complex series of instructions to an operator and – via the use of free text, drop-down menus or tick boxes – enable the operator to provide confirmation that a prescribed task has actually been carried out along with other comments.
This operator interface can be dynamically controlled so that, depending on the answer to a particular ‘on-screen’ question or instruction, the question path will change to ensure that the correct action is always taken.
In addition to this intuitive communication capability, every operator action may be recorded by the PSIM for the purpose of post-event analysis and/or training needs analysis, in turn offering a level of assurance not available with non-PSIM solutions.
Situational awareness (or situational management)
At this point I’d like to introduce the concept of situational awareness or situational management.
You may hear this term used instead of the acronym PSIM to describe the same type of system. Hopefully, having read the previous examples of how the rules engine and correlation engine can operate, you will start to see how PSIM offers much more than simple alarm event management via an integration system.
PSIM is a tool to aid situational awareness and not simply a system that collects alarm information from a range of other systems and re-presents it without any further analysis.
The next area of PSIM that we will look at is the geospatial engine. Different PSIM products achieve geospatial mapping in different ways. However, the basic function is to present the ‘situation’ or ‘status’ at any given time via 2D or even 3D mapping.
The map or screen image will typically include all input/monitoring devices which will change status in the event of activation. The mapping feature usually allows the operator to identify the location of an activation or the change of status of other devices and can aid the situational management capability.
Other benefits include identifying other devices within the vicinity, campus or estate management and incident management. Each PSIM software vendor offers a different range of additional features that should be considered on their own merits.
What of the future?
I hope that if you were unclear about the benefits of PSIM or the difference between PSIM and some other integration tools that this basic overview has helped clarify fact from fiction.
There’s no doubt that, as PSIM develops, it will continue to play a substantial role in shaping the global security arena.
The further broadening of interoperability standards and the continued convergence of IT platforms are two reasons why PSIM sales will continue to out-perform many other sectors of the security marketplace. That said, the main driver will be client demand.
As improved efficiency models and greater ROI occurs, it will be market demand that ensures PSIM vendors flourish and that PSIM continues to shape product innovation and development long into the future.
Jon Roadnight MSyI is a director of independent security consultant CornerStone
- Jon Roadnight has been working in the security sector for over 20 years. Having completed a Management Development course at Thorn Security during the mid 1990s, in 1998 he founded – along with business partner Narinder Dio – the Pearl Security Group which was established as a systems integrator. After six successful years, Roadnight and Dio sold the business to Novar plc.
- Following a short spell as the director, head of systems at OCS, Roadnight once again joined forces with Dio in 2006 and CornerStone was formed as a specialist security consultancy practice (www.CornerStonegrg.co.uk)
- The business has developed well and, for the last four years, has been a finalist in the Security Consultant of the Year category at the Security Excellence Awards. In 2011, the company won both the Security Consultant of the Year Award as well as the International Achievement Award.
- CornerStone provides a broad range of services from threat and risk assessments, physical security design and performance management through to project management functions as well as focusing on a number of specialist areas (among them PSIM design and implementation, hostile vehicle mitigation and policy and strategy development to name but a few).