The growth of VMS solutions in the video surveillance sector can only be seen as a positive. Open platform systems increase security, significantly enhance flexibility and add benefits for not only the installer and integrator, but also for the customer. Despite this, there are many designing and implementing surveillance systems who have yet to embrace the software, and the reason could be that VMS providers haven’t highlighted one of the best features on offer. Here Benchmark takes a closer look at rules engines.
One of the most advantageous tools for security installers and integrators looking to implement video surveillance solutions is undoubtedly the VMS. Video management systems (VMS) emerged into the security industry with the rise of network-based solutions, and since then have grown both in terms of popularity and functionality.
Because VMS packages are software-based, they do not suffer from the restrictions of hardware devices which are fitted with codec chips, input and output boards and other physical elements. This ‘soft’ platform allows the VMS a greater level of freedom, and additionally means that upgrades can be carried out on-the-fly.
Hardware-based systems will often require devices to be upgraded with new components to realise additional functionality, which means changes must be made at a manufacturing level. Units which are already deployed in the field will therefore need to be replaced to enjoy feature upgrades.
With hardware devices, many of the inputs and outputs, and their associated operations, are limited by these physical elements. The majority of I/Os provide a simple state change (On to Off, or Off to On) in terms of operation. Whilst it might be possible to set some criteria for how these state changes affect the system, the options remain limited.
VMS solutions, on the other hand, employ ‘soft’ I/Os and event management filters. These allow a greater degree of customisation, which in turn enhances overall flexibility and allows advanced performance. In the past, managing ‘soft’ elements used macros, software plug-ins or the addition of specific code snippets. Because of this some implementations required specific skills, and they weren’t greatly intuitive. VMS, thankfully, takes a different and far simpler approach.
VMS solutions generally have diverse settings for alarm I/Os as well as events (these can vary from system to system, and are at times associated to different menus). Typically, the former includes signals from attached devices and system-generated alerts such as tamper or failure warnings. The latter encompasses video analytics, site status changes, etc.. However, as VMS systems encompass ever more aspects of a site’s security (and site management too), alarms and events can include anything from area occupancy through to temperature and environmental monitoring. If data can be generated or measured by a field device, it can be included.
The rules engine (various manufacturers do use different names for this function) effectively manages the alarms and events, along with the subsequent actions these generate. This process can be as simple as increasing the recorded frame rate of a video stream when motion is detected, or sounding an alarm if IVA is triggered. However, rules can also allow complex structured scenarios to be created.
For example, multiple devices can be linked, or activity in one zone can change system attributes in another zone. The devices involved can be configured by time of day, day of the week or even by who is on site at any given time (if access control is linked to the VMS).
Criteria can be expanded to filter events. For example, if a vehicle enters a site during working hours, and turns left into a designated parking area, the system can either ignore the event or log it without raising an alarm. If it turns right into a loading bay, the event could be logged and a notification sent to the warehouse manager. If the vehicle stops and does not turn, or if it carries straight on, an alarm could be generated. Whatever the needs of the site, a rules engine can deliver specific and bespoke actions as required.
As long as a condition can be detected or data gathered about site status, this can be included in a rule. This allows rules to also encompasses non-security tasks. For example, if vehicle entry and exit counts on a car park are measured, barriers on an area without spaces will not open, and digital signage will direct visitors to an overflow parking area. Alternatively, using ANPR, if a vehicle not registered to the business is detected in a secure area, the system can raise an alarm and prevent egress by locking barriers.
This entire edition of Benchmark could be filled with possible scenarios, such is the flexibility of Rules. For those who have not used this element of a VMS, the obvious concern is that setting up complex scenarios is going to require some heavy-duty programming knowledge, but it doesn’t.
It is typically done via drop-down menus. This is thanks to a very simple but hugely effective approach known as Boolean Logic. By understanding the Boolean approach, the flexibility of a VMS with Rules becomes clearer.
Yes or no?
Despite being a core concept in algebra and mathematics, Boolean Logic is easy to understand. It also gives a clear illustration of how alarm handling and event management can be significantly enhanced. A system using Boolean Logic will certainly offer increased flexibility over typical security-based I/Os.
Boolean Logic is named after George Boole, a mathematician who wrote a number of books and papers on logic and mathematics. Boole’s logical approach sets out that the value of variables must be either ‘True’ or ‘False’.
When you consider that these are usually presented as ‘1’ and ‘0’ it becomes clear that Boolean Logic is instrumental in digital technology. It is an important element of all programming languages.
Boole’s thinking still shapes the solutions of today. Whilst having only two possible values might seem something of a limitation, what gives Boolean Logic a significant degree of flexibility is the inclusion of ‘Operations’. The most basic Operations are AND, OR and NOT, but there are many others.
In security systems, the Operations are pertinent to the tasks associated with the system. These can be used to create Rules which can vary from the simple and basic to the complex, dependent upon site requirements.
Additional Boolean Operations can be added and these can relate to any condition which is reported by the system. It can use motion and analytics reports from cameras, detector status, access door conditions, personnel details, time and date, etc.. With the right sensors it can even gather environmental information such as temperature and humidity.
That Boolean Logic is used in all computer programming languages underlines its inherent flexibility. In a recent VMS test in Benchmark, we set out to try and find a scenario that could not be managed with Boolean Logic-based Rules. Where appropriate data was captured by the system, we could not come up with any sensible tasks that were not achievable.
Many believe that because Boolean Logic is key to computer programming languages, it must be complicated. However, the simplicity of Boolean Values – True or False – makes implementation simple.
The vast majority of VMS providers have their roots in software rather than surveillance, and to them Boolean Logic is second nature. They also understand that the combinations of Values and Operations can be implemented to create complex scenarios.
Whilst all VMS solutions have variations in their methodology, a typical Rule is created by first selecting a device on the system and then adding various filters. These can relate to other devices, software tools or system data. Rules can be created to handle security, health and safety, business intelligence, site management and even system healthcare.
Rules typically can be configured in minutes, and can also be edited and tweaked from the VMS GUI to ensure optimum operation. The alterations can also be carried out remotely if required.
The definitions in Rules engine drop-down menus (often activated via a clickable link) will typically use names for devices, alarms, triggers and events which have been defined by the installer or integrator, so familiarity with the system is enhanced.
If the VMS can capture data to establish criteria, and can apply a True or False (1 or 0) value to an event, then a Boolean Logic-based Rule can be created. Whether simple or complex, it allows a system to be made smarter using a quick and easy method.
A hidden benefit?
Since VMS-based systems first arrived in the surveillance sector, many have offered advanced Rules engines. Some are better than others, and for those installers and integrators seeking to deliver bespoke solutions it’s true to say that if no Rules management is supported, the solution might not be worthy of consideration.
Despite a wide range of VMS solutions, the depth of benefits introduced by Rules engines sometimes go unnoticed. The reason is a simple one: those writing the code for VMS products come from a IT background, and people in that world take Boolean Logic for granted.
If you consider some VMS solutions, the features highlighted by the manufacturers tend to be based around connectivity. That’s because IT-centric engineers love connectivity! The security elements of the VMS such as Rules – the bit the installers and integrators love, and the end users pay for – don’t get as well promoted. General comments about ‘situation awareness’ and ‘threat correlation’ are commonplace, and fail to sell the security benefits of Rules.
As VMS becomes less about video management and more about overall system management, the Rules engines are of greater importance. For many, they are the sole reason to switch to software-based systems. Despite this, it is still common for the functionality to be explained via short and vague bullet points, usually simply stating ‘Rules engine’. The true flexibility, and its simplicity of implementation, goes unmentioned.
It is not uncommon to find that some installers and integrators don’t see the benefits of Rules, and this can be because of attitude. Too many people automatically consider events or activations as ‘alarms’. This often forces thinking about events into the traditional but inflexible trigger/alarm relationship. An event happens and an alarm is generated. That’s it: a simple non-filtered reaction occurs. This thinking is very much a product of many years working with limited hardware I/Os.
It’s important not to become bogged down with the thinking that an input can only be an alarm. By linking other types of event, such as those generated by management-based systems, the Rules engine can add significant benefits when a site is manned and active. The inputs don’t have to be security-related.
Increasingly, solutions can include an interface to data-generating devices. These can include POS systems in retail applications, ATMs in financial institutions and logging systems in warehouses and logistics operations. The information flow can not only be recorded as data, but can also be used as event triggers.
For example, POS units could store sales transactional data along with associated video, but could also instigate events if, for example, a ‘No Sale’ till opening occurs.
Video-based event triggering is popular in the creation and use of Rules, and for good reason. The data that is captured contains more information than is available from a simple detection device. Consider a motion detector installed outside of a building. If someone approaches, they will be detected and a signal is sent to the system. The cause is established as motion in a designated area.
Whilst this is all well and good, the detector simply informs the system that motion has been detected. There is no further detailed information. All that an operator can glean is that somewhere, in the field of view of the sensor, movement has taken place.
If the detector is reset before the target is out of view, another instance of motion might be generated. The operator won’t be able to tell with certainty whether the second trigger is from the same source or another occurrence in the same place, nor can they discover what caused either event.
Video can deliver a higher degree of information. It can identify where in the field of view that motion was first detected. It can track individual targets, and can generate a ‘trail’ that clearly illustrates the path taken by the target whilst travelling in the protected area. It can identify where the target stops, and for how long. With much more information available, the criteria for establishing and filtering Rules can be greatly expanded.
Taking a different attitude to events through the use of Rules can result in added value for end users. By not treating every trigger as an ‘alarm’, a greater range of benefits can be delivered. Boolean Logic can be used to deliver useful management information just as easily as it can deliver enhanced security.
The creation of bespoke sophisticated scenarios allows the user to monitor staffing levels, approximate waiting times for customers, workflow backlogs and a host of other business variables. Rules can also be useful during emergency situations such as site evacuations.
Detailed site information can be collated into reports and used for site management purposes, without any need to review associated video footage. Those who benefit from the information have no need to interfere with the day-to-day running of the system. The Rules can work in the background, transmitting the specified data on a regular basis to identified personnel.
Indeed, Rules can be established which trigger separate Rules when the situation demands it. This allows the site status and ongoing events to control other system attributes automatically. thus opening up a layer of flexibility that is very difficult to achieve with systems using hardware I/Os.
In summary
If an installer or integrator limits their thinking about events to a simple trigger/alarm concept, then achieving a bespoke solution using VMS-based Rules will not be possible. The thinking that systems must be based upon such relationships has existed for many years. However, that was because more flexible relationships simply were not possible without additional devices that could result in projects not being financially viable.
With a Rules engine, the security industry has the technology to deliver smarter solutions; installers and integrators need to adopt a more flexible attitude to system design and implementation in order to realise the full potential on offer.
