Video Surveillance RFPs Reviewed - Vol 1

Published Nov 09, 2010 00:00 AM
PUBLIC - This article does not require an IPVM subscription. Feel free to share.

In this report, we review 4 recent real-world video surveillance Request for Proposals (RFPs). 

RFPs provide a good look into the needs, challenges and desires of actual security end users. In our first volume, we review:

  • A Transit Center
  • A Police Station
  • A School District
  • A Housing Authority
  • Here we examine an operations and maintenance center for a California City's transit/metro service. For background, review the 71 page RFP [link no longer available] for yourself.

    Key attributes of the system include:

    • 19 total cameras, all IP
    • 4 PTZ cameras, SD
    • 15 fixed cameras, all 1.3MP
    • All parts and pieces from Pelco including VMS and storage

    Our observations:

    • As this is a California city, Pelco's ability to hard spec their offering is not surprising (given their local marketing strength).
    • We are surprised though that a government bid has been so tightly specified around a single vendor (many other vendors offer the same solution so it's hard to understand how one can make a single source justification).
    • This is a relatively small camera count deployment yet it went IP.
    • Megapixel is likely the driver to IP. The only element that was not megapixel was the PTZs. If this spec was developed a few months later, it would likely have included the recently announced MP Spectra's.
    • Also, if this spec was developed just a few years ago, it would be hard to believe that Pelco or their channel would have advocated an IP/MP solution.
    • Given that the physical area that many of these cameras are covering is large, megapixel enhances surveillance coverage and probably allowed them to specify less total cameras than if it was an all analog project (see the camera locations map on page 56 of the RFP [link no longer available]). Most of the cameras specified were domes, specifically the ID10DN8-1 that has an average online price of $720.
    • (2) 16 channel NVR appliances were specified. It appears that they are being deployed at the same location, so we are not sure why they did not simply purchase software licenses and a COTS PC/server.
    • The biggest surprise is the specification of two 9 TB SANs to be directly attached to each NVR appliance. The model, the DX8100HDDI [link no longer available] (a Pelco OEM of an Infortrend product), has an average online price of $22,000 [link no longer available]. Essentially, the city will likely pay more than $40,000 for less than 20TBs of storage - which is an extremely high cost even for a top quality storage system in 2010. Also, since the storage is segmented into 2 pools that can only serve a single NVR each, it scales poorer and will likely be more wasteful than a network based SAN or NAS device.

    Police Station

    Here we examine a US town's video surveillance system RFP for their police department headquarters. Rather than issuing a performance or product specification, this town has taken a much less common approach of letting each bidder design their own solution. The town will then interview and potentially negotiate with selected responders. Review the town's video surveillance RFP.

    Let's first examine the town's current system and needs:

    • Existing system first started in the mid 90s and now has 3 DVRs and more than 40 cameras.
    • Various system components are failing.
    • The town is looking for a major upgrade to an IP based system that eliminates multiple passwords. replaces the analog matrix system and integrates audio at all sites.

    The RFP is extremely vague and only 5 pages long. As the town notes, "the intent of this RFP [is] to have a qualified, experienced contractor survey the facility, perform a needs assessment, design and engineer a solution to upgrade the existing CCTV system within the parameters contained."

    Some observations:

  • Design: We are skeptical of how thorough responders will be in designing a solution from scratch for an open bid that leads only to a second round of competition. It's an expensive proposition for the responders. The town is likely to get each responder to pitch their lead VMS.
  • Passwords: The town specifically called out the multiple password problem for each DVR as a significant problem. We are not surprised about this as it is both a usability headache and a security concern. On the other hand, the town must expect to pay a premium to eliminate this problem - likely on the order of $100 more per camera or about $4,000 as systems with enterprise management almost invariably cost significantly more than those that do not.
  • Old System: It is not uncommon for municipalities to keep surveillance systems for a long period of time (7+ years). Note that while the town has likely been repairing and replacing components for years, only now has it moved to do a major upgrade.
  • Jump to IP: Given how infrequent the town does upgrades, the move to IP makes sense as a platform for the next decade.
  • Audio: In analog systems, audio had implementation barriers, requiring separate cabling, microphones/speakers and often restrictions on audio inputs/use in DVRs. Certainly, IP cameras will make this easier as microphones are routinely built-in and no additional cabling or recorder inputs are required. Additionally, our Camera Finder shows that 298 of 508 cameras have listening capabilities built-in.
  • Digital matrix: While the town asks for a digital matrix, we assume that they will simply use their VMS client capabilities to display live video. Given that this is a police station, we would suspect that live monitoring of PTZs is a secondary concern (the primary reason to keep or enhance analog matrices).
  • Encoders or Hybrid DVR: While the specification is silent on this point, this will be an important decision. It appears that the town will try to keep at least some of its existing analog cameras. For an organization that moves as slowly as they appear to, we would think hybrid DVRs would make the most sense as they are the least expensive and simplest path for IP migration.

School District

A County's RFP for school district video surveillance requests both access control and video surveillance software. It's not much of a specification, though, as the requirements are extremely vague. For background, review the School District RFP document [link no longer available].

Here is the County's current conditions / needs:

  • The primary installation is for card readers for the access control system.
  • The RFP states the school already has Pelco IP110 cameras installed. These are the 'pre-Sarix' 4CIF, MPEG-4 IP cameras.
  • The school already has a network and a SAN (Storage Area Network) so the supplier need not provide connectivity nor storage.
  • The RFP is silent on any specifics of the VMS software. We suspect they want the access and video integrated but this is not explicitly required.
  • The RFP is for multiple school districts covering 7 different building configurations. The RFP allows each school district to select independently.

Our observations:

  • The lack of detail is problematic. While we expect that many questions will be answered during the 'verbal interpretations' period where vendors ask questions, this is a poor way to communicate requirements as it can be confusing for respondents and may provide incomplete or contradictory specifications.
  • The only requirement for the VMS is that it supports the Pelco IP110. That, in itself, actually will be limiting as only a dozen 3rd party VMSes support this older camera line.
  • We anticipate the school will want their access integrated with the VMS. This will limit choices even further.
  • If the County wants interoperability amongst the schools without buying a PSIM or command and control system, they will almost certainly have to choose the same VMS/access control systems (even if they purchase independently).
  • Using the school's own SAN could be useful though we wonder how large the school's SAN is and how much they might need to expand it to accommodate the surveillance system. The specification is also unclear whether there are SANs physically located inside of each school (which would be needed to eliminate sending video offsite and over the WAN).

Housing Authority

This video surveillance RFP is for a housing authority covering more than a dozen sites. The RFP is specified in extreme details and, in may cases, too detailed or contradictory. For background, review the 154 page Housing Authority video surveillance RFP [link no longer available] document.

Key attributes of the system include:

  • 15 sites/complexes require surveillance
  • Video shall be monitored both locally at each site and at the Housing Authority's main office.
  • At each site, a recorder and a large monitor (50"+) will be deployed. Video will be recorded locally and made available over the Housing Authority's 10MP MPLS WAN connections (to the main office).
  • Cameras must meet various resolution requirements ranging from 20 pixels per foot (ppf) for detection at entrances and parking lots to 60 ppf for 'strong identification' at choke points
  • The VMS system must be about 30 pages of extremely detailed specifications for numerous functionalities including specific 3rd party support, methods of enterprise management, video export, display, etc.
  • Camera technical specifications are quite detailed (see page 35 of the spec [link no longer available]): 4CIF to 2MP resolution, day/night cameras, minimum illumination: .18 lux, H.264, auto back focus, dual streaming, alarm inputs and outputs, etc. All fixed cameras are to be vandal proof domes. Additionally, bidder must determine and supply IR if needed.
  • Unlicensed 2.4, 4.9 or 5 GHz wireless links must be resistant to interference from tree / foilage growth.
  • At the main office, the Authority wants (9) 50" monitors in a 3 x 3 matrix for monitoring video. The monitoring station is not staffed 24/7.
  • No video analytics are specified.

Key observations:

  • Milestone Enterprise only VMS that matches: From the various low level specs included (Master/Slave setup, Digifort and Verint camera support, iPix compatibility, 'speedup' settings, etc.), this is almost certainly requires bidding Milestone Enterprise. This restricts competition by artificially introducing unnecessary requirements (e.g., does the system have to do enterprise management by the antiquated master/slave approach? are iPix settings really needed? etc.) We think the customer would be better served by issuing general performance specifications and let bidders offer multiple VMS choices. This is also a confusing and wasteful approach as 30 pages of specifications could have been replaced with a few lines to show their true intent (though this is a frequent tactic). Secondly, if the client really want Milestone, we think Milestone Corporate would be a significantly better choice than Enterprise. Corporate has superior enterprise management, alarm handling, video distribution, etc.
  • On-site recording: Recording the video at each site is not surprising. Even with a 10Mb/s WAN connection, insufficient bandwidth is available for moving numerous dozens of camera per site to a central location.
  • Pixel Per Foot specifications: We think specifying pixels per foot is helpful but a minimum horizontal Field of View (Fov) in feet should also be specified (e.g., 40 ppf at a 20 foot wide FoV). Without specifying the horizontal FoV width, bidders can not be sure what resolution camera to choose. For instance, if one bidder estimates the FoV to be 20 feet and another 30 feet, insufficient resolution will be provided for the narrower estimate. This is especially hard as, by definition, any camera can provide 60 (or 120) ppf if you accept a narrower enough FoV. Readers repeatedly expressed confusion on this point in our PPF study.
  • Vandal Domes: The choice of camera housings are not surprising. Indeed, the number of IP vandal domes has grown significantly over the last 2 years as domes begin to outnumber box cameras. For example, over 100 vandal domes are listed in our Camera Finder.
  • Minimum Illumination: A minimum illumination  of 0.18 lux is essentially meaningless as camera manufacturers have no standardized, comparable way of comparing low light performance. Setting a number only invites and rewards those manufacturers who fabricate or rig unrealistic numbers. It may sound crazy but given who manufacturers set their min illumination rating, the Authority would likely be better off just specifying a mechanical cut filter and leaving out minimum illumination altogether.
  • Auto Back Focus: The specification requires auto back focus but that one requirement limits options from about 26 cameras who meet the other requirements to less than 10 who also support auto back focus. While auto back focus is valuable, it does add about $100 average more cost and limits options.
  • IR Illuminators: The spec is vague on requiring IR illuminators: "Bidder to determine if IR is required to supplement existing lighting." The problem is that determining when IR is needed is subjective and also dependent on other settings used. Quality of image degrades gradually with less light so disagreement can arise as to when video becomes unusable. Also, a savvy or manipulative bidder can set longer exposure times 'providing' more light at the expense of motion blur. Specification would be improved by listing the longest exposure time allowed.
  • No video analytics: Given that these are large housing areas with on-site guards at some sites, real time alerting from video analytics would almost certainly be useful. Furthermore, given the amount spent on this project, it is likely they can afford the minimal extra cost. On the other hand, given the lack of confidence the community has in analytics, this is not surprising. When analytics truly goes mainstream, every project like this should include analytics (much like they are now including megapixel).