Pros and cons of having your cameras smashed
Large-scale video surveillance systems, ones of corporate level, utilize hundreds, even thousands of cameras. In such conditions it’s hard to keep tabs on whether all cameras are always online, or if the video surveillance system is functioning well.
That’s when automated video analytics of the so-called sabotage detectors come in especially handy – notifying operators and administrators about the threat or a criminal act in progress.
First victims of vandalizing are usually cameras themselves. Criminals try their best not to be filmed (that’s why it’s essential to project their placement right in the first place) and, if that’s hard, tend to eliminate the threat.
Vandalizing or breaking the cameras is the most frequent offenders’ choice. This might not be the cheapest scenario for video surveillance system’s owners, but on the plus side, operators will detect that camera was disabled that very instant, and take urgent measures. However, this is not the case for VSS that run for years and years without human supervision: not only is equipment damaged, valuables stolen, without any evidence of who did it, but also videos of other episodes can go missing before it is detected that the system isn’t working.
Another scenario includes more tech-savvy criminals who cut the cords for the cameras, for example, Ethernet wire where the camera stops sending its stream and the image freezes. Camera itself is not vandalized which is a plus, but on the other hand, the last received frame of such “frozen” cameras would hang on the display like it’s all good for a long time, without giving away that the cams have been tampered with, allowing wrongdoers operate from the comfort of a blind spot and then leave the scene unnoticed with their loot.
Best case, from the point of view of video surveillance system’s owners, would be if the camera is turned – simply pointed in another direction, blinded with a flash of light (for example, with car’ headlights) or obscured, for example, with a piece of cloth or a bag. The only damage here is what the criminals will take from the guarded site while the cameras are not watching. Technically, cameras are fine – they are monitoring a site all right, but not the site they should. If there are many cameras to monitor, operators may miss this little change and, consequently, miss the criminal act that was going on right under their nose, just like in a classic spy movie. No records and no evidence to prosecute.
State-of-the-art video surveillance software have embedded video analytics that notify all authorized personnel not only when motion is detected in the field of view of cameras. They will also send alerts about cameras being tampered with – sudden changes in camera’s image (too bright or too dark), angle, lost connection or “freezes”. Moreover, enhanced video analytics systems will even let operators and/or administrators know when the “health” of the whole system is at stake: free disk space or RAM running out, database changes or incorrect server restart is detected. Notifications are available in the form of your choice, from emails to SMS and to a sound alarm.
Sabotage detector in Xeoma
To provide unsupervised system health monitoring Xeoma offers not just edge-cutting on-screen diagnostics but also the “Problems Detector” module. Video analytics behind this sabotage detector provide automatic notifications of the form of choice about the scene changes (when camera is being tampered with) or when system’s “health” is involved.
Enhanced video analytics, flexible configuration and modular structure help you set up the system to give notifications for certain cameras when you want them. For example, you could send a notification to the system administrator when signal from one camera is lost but when it’s another camera – guarding the safe – trigger an alarm at once. Several types of notifications can be connected to the same camera.
Error messages are also shown on-screen. With the right font size you will not miss Xeoma’s warnings:
System health monitoring goes a longer way with Xeoma solution and lets it check availability of network resources (modem, website, etc) too. To do that, just enter the address of a network resource (for example, IP address) and interval of availability check.
“Problem Detector” can also save information to a log file
The log file is named ProblemsDetector.log. It can be found in the Logs folder in Xeoma’s folder. There are many messages the log may contain about scene change or system health issues, here is the full list:
- RAM is running out
- The RAM problem is resolved
- The server was restarted incorrectly
- Disk space is running out
- The disk space problem is resolved
- No free disk space left
- Camera image too dark
- Video stream is no longer too dark
- Video stream is no longer too bright
- Camera image too bright
- Camera turned or obscured
- Camera is no longer being turned
- Database update error
- Database reading error
- Database writing error
- Audio stream received
- Video stream received
- Camera image is missing or isn’t changing
- The network resource is not available anymore
- The network resource is available again
- High processor load
- Processor load normalized
- Image is not refreshed
- No camera stream (video or audio) entirely
Starting with beta version Xeoma 20.10.13 added the ability to work in combination with filter modules (for example, with the “Scheduler”).