USING CCTV FOR REMOTE ALARM VERIFICATION
"Agh!" goes the anguished cry of a loyal CCTV Today reader who can't see the point of yet another article about remote video monitoring. "Pushing pictures through tiny telephone lines is old hat now. If I'm going to spend ten minutes reading this, make it worthwhile."
Well you've made it this far, so indulge me over the next paragraph, and I won't be offended if you decide to move on to the next article that may be more your cup of tea.
My purpose here is to cover the key points that will enable a technophile reader to form a 'cunning plan' to establish or upgrade a CCTV system so that it can be operated from somewhere so distant that their own CCTV cables won't stretch that far. I will not discuss the merits or otherwise of ACPO 2000, or comment on the hoo-ha associated with PAS 38:2000. I will follow a thought process, which covers a checklist of the chief considerations, and will make references to the requirements of the new PAS 38:2000 "Installation and remote monitoring of detector activated CCTV systems - Code of practice". Written with ACPO 2000 and alarm confirmation in mind it states that compliant systems should be able to obtain response from the Police, and I recommend that you read both documents for full details.
Much as the following few points have been covered as nauseum in the security press for several years now, let's go over them again briefly to get the right cogs turning in all our heads.
Q: What is 'remote'?
Q: How do I approach
a project like this?
Q: Why consider running
my CCTV operations remotely?
Q: Are there practical
differences between operator-driven and alarm-driven systems?
Q: What communication
methods are available these days?
PSTN: a standard telephone line with a modem running at 56Kbits/sec. To see how quickly these systems transfer pictures (and the reciprocal arrangement with image quality), get a demonstration CD from any of the many companies who advertise p.c.-based systems in CCTV Today, and see if you can live with the results. To sound a note of caution, a BT engineer told me that RedCare and modems don't mix on the same phone line. Keep them separate.
GSM: cellular phone technology that is used to send data at 9.6Kbits/sec, which is less than a fifth the speed of PSTN's impression of treacle. Hope is not lost! With the same gusto that they tried to flog you WAP handsets, the men who won't let technology get in the way of a good marketing campaign bring you GPRS followed by 3G, giving great leaps in speed that will enable you to download video onto your laptop at the beach. Get psychiatric help first to address your worrying obsession.
ISDN: a truly digital service down your phone line that can run reliably at 64 or 128Kbits/sec. Dial-up is almost instantaneous. Again, see if this meets your needs by running demos at various settings of picture quality. If you are a devotee of RedCare then ISDN can accommodate this now.
xDSL: this is the famous 'broadband' down a regular phone line that can run at 2Mbits/sec. Of course, the higher-tech we go, the greater the cost to establish the service and the monthly bills. Note that the ADSL variant can receive at 2Mbps but is limited to transmitting at a quarter of this speed.
RS3000: a service provided by BT that gives a dial-up channel of 2Mbits/sec. Having seen this working I can say that such a bandwidth is capable of giving pictures that are practically indistinguishable from 'live' pictures, e.g. long-distance optical fibre.
WAN: this will be an in-house backbone that sends data all over the corporate empire. Your network manager colleague will be keen to keep all his data free-flowing, and allotting you 10Mbps of his seemingly vast 100Mbps capacity for purely CCTV use may be, for instance, a problem in the daytime but no problem at night when everything else is quiet.
PAS 38 makes mention of the ACPO 2000 requirement for a 2nd signalling path to be present between the protected site and the RVRC to permit communication if the primary path fails, especially through sabotage or alarm equipment fault.
Now from a purely CCTV point of view, it is important that the remote monitoring and control equipment is compatible with the aforementioned equipment on the protected site(s). Video signals can conform to the CCIR standards and be universally useful. However, camera telemetry, switcher protocols, audio intercom, access control systems, etc. are often proprietary and should be considered with care before entering into a commercial arrangement with, for instance, the 3rd-party RVRC who will probably have invested in equipment from a range of manufacturers to entice a wide range of clients, but may by no means guarantee to be able to accommodate your signals.
Back to the question about the few differences between user-driven and alarm-driven systems. The paragraphs above indicate the similarities. The bits that transform the former into the latter by the use of some automatic features are described. The triggers that cause the system to signal an activation as far away as the RVRC can be many and varied: PIR's, video motion detection, microwave fence zones, subterranean pressure sensors, microphonic fence cable, vibration sensors, door contacts, fire alarm, visitor intercom call, access control token reader usage, plant/process measurement threshold alarms, etc., and as many more as your imagination can invent. All of these inputs need to be fed into one or more control units of the appropriate standard. For instance, the intruder detection sensors and control panel should conform to the correct BS4737 or BS EN 50131 requirements, and should have the necessary certification. Detectors should be of a suitably good design to ignore unwanted stimuli, and thoughtful combinations, e.g. paired motion detectors with differing sensing technologies can enhance such a first step in designing-out unwanted activations.
CCTV camera arrangement should follow BS EN 50132-7. Each field of view should at least cover the detection area of any associated alarm sensor. Take into account the portion of the image lost in CRT video monitor overscan of ~10%. Also consider the time taken for PTZ cameras to re-orientate themselves from the worst-case position to acquire their target. Motorized lenses can take an appreciable time to zoom and focus to preset positions, even if a super-fast pan/tilt mechanism is employed. An intruder should still be in the field of view by the time this has been achieved.
While it should go without saying that a CCTV system is useless without the correct illumination for all occasions, the resulting image clarity can be destroyed by low quality image transmission to the RVRC. The stipulation that a Rotakin target should fill 10% of the screen height to enable the operator to quickly see an intruder was made for a CCIR picture format where, at worst, a single field of video (from a vcr playback, for instance) comprises ~288 lines in the raster, giving a certain vertical resolution. Now what if we choose to send digitised video to the remote operator in CIF format? Fine. There are still 288 lines. But what if we want a faster image update rate and choose to send QCIF images? The operator sees an image with only half the resolution and may well have difficulty making a judgement as to the action that needs to be taken owing to poorly presented information. This point isn't in PAS 38. It's just a thought
Of course, the intruder alarm setting/unsetting routines and signalling of such to the RVRC should be strictly observed and, quite literally, might do well to be observed by a camera to provide visual information surrounding activations associated with entry/exit routines.
All suitable tamper resistance and tamper detection measures are recommended, so that the integrity of the systems and stored data is assured as far as possible, and any failures are signalled to the RVRC immediately to be investigated and notified to the owner. As you would expect, power supply backup is essential.
In the event of an activation, of particular importance to the RVRC in carrying out an alarm-driven monitoring service is the ability to review the apparent causes of alarm activations so that a measured response can be made. It is easy to imagine that this would normally involve reviewing the very recent history of the camera that has a view of the particular alarm device. How is this done when several seconds may have elapsed before the RVRC operator is presented with 'live' pictures? The operator cannot effectively carry out a quick rewind of the local videocassette recorder, but a remotely controlled backwards search through a digital random-access memory is quite feasible and does not disrupt continued recording of all other cameras on site. Your chosen interface unit that allows you to send your CCTV to the outside world may well provide this short-term video memory, and automatically send a pre- and post-activation video sequence to the operator at the RVRC. However, you may choose to use a fully-fledged digital hard-disk video recorder at the protected site instead of analogue tape recording, and this will kill the proverbial two birds with one stone.
Having just developed some momentum here I need to draw to a close. It is not unusual to realise at this point that the various aspects of this broad subject deserve a whole chapter of a book each. These few words have skated across the surface of what will definitely be a hot topic, well beyond the time when a clear way forward has been established and we cease to be frightened of getting it wrong. The surveyors and designers should partake of some proper training in these matters so that they can deliver what their customers need in this brave new world. Much of what has worked for the past twenty years may not be appropriate anymore. Still, it keeps the independent consultants in demand, especially those who specialize in steadying those troublesome moving goalposts.