The market is being whipped into a frenzy by buzz about IP, yet studies show that only 10-15 perent of systems sold include IP cameras. What’s the deal?

Our firm was recently retained by a new client to provide a strategic review on the electronic security industry. This client was focused on CCTV, and inevitably the topic of IP-based CCTV systems was high on their list. They had studied all of the market data they could find and were disappointed to discover that — depending on the estimates — only 10-15 percent of the systems being sold today are considered IP systems. “How can this be?” they asked. “Aren’t all systems today essentially IP based systems?”

They were right. Unless you are using a videocassette-based system or an extremely low-end DVR, all systems are IP based. Why? Because the recording is handled by a DVR, and that DVR virtually always includes client software that allows you to remotely access live or recorded video. So, if all systems are IP eventually, why is there so much discussion as to the pros and cons of IP based systems?

Close to the Edge

The real question is how far out to the edge do you go with IP. An IP system converts an analog video signal to a digital stream that can be transmitted over a conventional Ethernet network. But it can do this in a number of places.

If an IP camera is used, the signal is converted at the camera itself — this is what is commonly referred to as an IP-based system. An analog camera can also be used, and the signal can be fed into an IP encoder that converts the signal to a digital stream. The IP encoder can be located in a more convenient location, and multi-channel encoders are available to convert multiple cameras from one box. Or the camera can remain analog all the way to the recording device, which then converts the signal to store it. In that case, the recorder is also serving as an encoder, and the signal is generally available as an IP signal streaming from the recorder.

So, which system should you use? In general, we recommend that analog cameras be fed to IP encoders unless megapixel resolution is required. We base this on a number of factors, including cost, ease of installation and appearance.

1. Cost — In general, the cost of an analog camera plus an encoder is generally the same price or less than the cost of an IP camera, and technically the signal quality is identical. In fact, if multi-channel encoders are used the cost of the analog/encoder pairing drops significantly below the IP camera cost.

   The true savings come in when you look at replacement cost. Edge devices fail or get damaged from time to time. One of our clients had a faulty camera installation and the outdoor IP camera filled up with water during a storm. Replacement cost was $900, but it would only have been $300 if an analog camera had been used and connected to an encoder that was safely installed in a closet or other weatherproof space.

2. Ease of Installation — An IP camera has some installation limitations that can drive costs up significantly. Primarily is cable distance — IP cameras are limited to 100 meters (328 feet) unless special converters, repeaters, or fiber optic cable is used. Analog cameras can run for great distances before being converted to IP — over a mile if the proper UTP (unshielded twisted pair) baluns are used. The same cabling can be used, so cable cost isn’t an issue, and the convenience of locating equipment where conditioned space is available often outweighs other concerns.

   Other installation factors include the sensitivity of IP cameras to power fluctuations, the difficulty in getting environmentally hardened IP equipment, and the limitations in size and form factor for IP base products.

   Finally, analog cameras can be plugged into a portable monitor for setup, focusing, and field of view adjustments. While some IP cameras also include analog outputs to allow this, many do not. This makes installation far more difficult, involving a computer, extra network port (if power-over-Ethernet is used) and added time and complexity when installing.

3. Appearance — We are currently in the golden age of analog cameras in that the variety of sizes, shapes, features and performance levels available at low price points has never been better. This gives the designer or installer tremendous flexibility in matching cameras, housings, lens types, and other specification features to capture exactly the image that is needed. Too often, IP cameras require aesthetic or performance compromises that do not go over well with end users.

   While these and other advantages make us lean in this direction, nothing trumps technical requirements. If your application makes IP cameras advantageous, feel free to mix and match or use whichever makes the most sense. As far as which type of device to use, keep both in your toolbox and remember the old adage; if the only tool you have is a hammer, pretty soon everything looks like a nail.

DVR Versus NVR

To convert a camera to a digital signal it must be encoded. There are three ways of doing this. First, you can buy an “IP” camera which has an encoder built into it. We don’t usually recommend this, as when the camera breaks you have to replace the camera and the encoder at the same time, since they are one unit. Second, you can buy a separate camera and encoder. This allows you to just replace the device that fails which, over time, will save money. Third, you can buy a digital recorder with an encoder built in, and just plug the analog camera into the recorder.

A device that records signals that have already been encoded (options No. 1 and 2 listed above) is called a network video recorder, or NVR. A device that has the encoders built in (option No. 3, above) is called a digital video recorder, or DVR. It gets a little more complicated as there are units that have some encoders built in and also record encoded signals. They are usually called DVR’s as well, although they’re really both.

Functionally, there’s not a lot of difference. In fact, many manufacturers make both types and a system could use both. For example, a shopping mall might put a DVR in their command center to record the cameras that were run directly back to that room, and put encoders in data closets that would stream back to NVR’s, also located in the command center. When viewing cameras, they wouldn’t be able to tell if they were plugged into an NVR or a DVR, and they could view both types side by side on the same monitor. In most cases, the primary concern is cabling, infrastructure, and ease of installation since the recorded and live images are identical with each type of technology.

Click Here to download this article in PDF Format

Now more affordable than ever, UPS units have become an essential piece of equipment in myriad settings, from large data centers to home entertainment systems. But nowhere is a UPS application more essential than for security. In a day and age when most products incorporate microprocessors and, therefore, require boot-up time, UPS units have become even more critical. Consider a half-second loss of power to a system could easily result in a reset time of several minutes or longer – an unacceptable episode for equipment that requires 100-percent uptime, such as surveillance cameras and access control systems.

While UPS systems are designed and specified differently depending on the manufacturer, there are some commonly accepted guidelines that, for the most part, apply to all. I’ll do my best to address the most common questions here in a question-and-answer format.

Q. What equipment should use a UPS?
A. In the event of a power sag or outage, a UPS functions to reduce the chance of equipment damage or time delay for rebooting. Any equipment that fits into this category clearly needs to be protected.

A secondary category is equipment that requires 100-percent uptime, such as surveillance cameras, access control systems and other electrical devices that cannot be manually operated during an extended power failure.

The third equipment category often receives less consideration, but can be no less vital: ensure that you have a UPS on accessory devices that will be needed during a power outage. These include rack service lights, keyboard-video-mouse (KVM) switches, cordless telephones and similar devices.

Q. How are UPS sizes determined?
A. A UPS system is sized by two determining factors: runtime and load rating. The latter figure often receives the most attention because it represents the amount of power the UPS is designed to supply. A good rule of thumb here: the UPS should provide an amount 25-percent greater than the cumulative power requirements of the attached equipment.

The significance of the runtime figure must not be misjudged. This rating determines how many minutes the UPS will continue to provide power at full load to the connected equipment. If an 800 volt-amps (VA) UPS has a runtime of 15 minutes, and a longer runtime is required, operate it at half load to almost double the runtime.

Q. How much runtime is required?
A. Most power brownouts last a few seconds or less, so a UPS with limited runtime is perfectly suitable for applications in similar periods of reduced voltage. However, the runtime on a UPS should be specified either to exceed the worst-case downtime or to allow the orderly shutdown of attached equipment.

If your facility has a generator, the UPS need only bridge the gap between the loss of utility power and the availability of generator power. In event of power loss, modern generators are able to come online in a matter of a few seconds. Older equipment can take up to 10 minutes or longer to kick in if the generator isn’t well maintained.

To be most prudent, figure 20 minutes of runtime at a minimum – no matter how modern the generator. Thirty minutes is good for older generators. And if the unit can’t be brought online in half an hour, chances are your system will be shutting down.

Note that too much runtime isn’t practical. It will increase the cost of the UPS system exponentially, add size and heat, and won’t likely give you a tangible benefit. Why? Because most power drops are extremely short in duration. There will be more batteries to test and maintain, and the maintenance expense will be significantly higher than a UPS that has been sized correctly.

Q. My equipment says watts, but my UPS says VA. Are they the same?
A. No, and this is a major issue when deploying a UPS. To calculate the wattage (W) rating of a UPS, manufacturers multiply the VA rating with a “power factor” or the actual amount of power drawn by the equipment. So, a 1,000VA UPS specified with a factor of .8 will deliver 800W, while a similarly specified UPS with a power factor of 1 will deliver 1,000W, both at the rated runtime.

Since UPS factors can range from .66 to 1 (modern computers can be as high as 0.97), disregard the VA rating and focus on watts. If you can’t find the wattage rating, contact the manufacturer or move on to another unit.

For the complete version of this story, see the November issue of Security Sales & Integration magazine.

Copyright © 2009 Security Sales & Integration. All rights reserved. All material on this site including but not limited to images and text may not be duplicated, reproduced, redistributed or re-transmitted in any form without the express written permission of Security Sales & Integration.

Click Here to Download this Article in PDF Format

Like many of today’s modern technological conveniences, electronic security products typically require a year or more to get from the drawing board to the stock room.They are the result of countless hours of brainstorming, research, development, testing, production,marketing and support. How do manufacturers do it? Take a journey with a mythical product to find out.

Every motion sensor, DVR, card reader, control panel or any one of thousands of other electronic security and fire/life-safety devices in existence today was once just an idea put forth by one of our industry’s manufacturers. Most installers and end users take these products for granted as useful devices to be sold and used. However, each of them undergoes a long, rigorous process of research, development, testing, production and marketing.

Most manufacturers would agree — particularly if you talk to their customers or marketing and sales folks — that the time and cost involved in bringing a new product to market is substantial. Larger suppliers often have a gauntlet an idea must run in order to ultimately become a product. Smaller companies, on the other hand, are often surprised by the ramifications of skipping such “unnecessary” steps. Yet, if you were a fly on the wall at their meetings, you would likely hear a common plea: “Can’t we do this any quicker?”

To shed some light on how this all works, we’ll take a product through the entire process. We’ll explore the elements that go into a product design, and the millions of dollars and years of work involved for even fairly simple technology products.

To accomplish our task, we’ll create a fictional product. Since DVRs are popular now, incorporate hardware and software in their design, and are going through rapid innovation, we’ll go with one of them. Our manufacturing company will be a fictional but established player, with the infrastructure to design, build, distribute and support their products. Finally, we’ll stick to available technology — no holograms, nanotechnology, smoke, mirrors or magic will be used in the making of our product!

Idea Defined Based on Customers, Competition, Cost, Uniqueness
To design our product, we’ll first need to define it. Paradoxically, this step is both the simplest and the most difficult. It is simple because we already have a pretty good idea of what we’re going to do. We know what business we’re in (electronic security) and the kind of product we want to make.

Our customers have repeatedly told us what they’d like to see in our new DVR, and we have a rich field of competitors to mine for ideas. We know what price point we need to hit, what our capabilities are, and what it takes to put together a first-class product. So what is so difficult about defining a product?

With few exceptions, companies like ours don’t want to create “me-too” products. This means we need something of a crystal ball to predict the features our product will need when it finally hits the market, to avoid it becoming obsolete too quickly. We’ll need some “secret sauce” that makes our product stand out and gives customers a reason to select it. And we’ll want our product to be marketable for as long a period as possible; the longer it remains marketable, the more of our investment can be amortized.

Keeping our product marketable is a tremendous challenge. “Ten years ago, we saw products having 10- to 20-year lifecycles,” remarks Dave Smith, vice president of marketing for Pelco in Clovis, Calif. “Five years ago, it was around five to 10 years. With the current pace of technological innovation, today’s product designs can be expected to be obsolete in as little as two to three years.”

Other manufacturers agree, some placing the product lifetime at as little as one year. “Determining the market needs and ultimately the features required are generally the most critical and hardest to predict,” says Bret McGowan, vice president of marketing at Vicon Industries in Hauppague, N.Y. “Product development takes a long time and attempting to forecast the needs of the market at the time a product will actually be released requires a significant understanding of the trends in the market so that when it comes out, it’s not behind the curve.”

To define our idea, we’ll generate a Market Requirements Document, or MRD. This document will be a best estimate of what features the market is looking for, how much folks are willing to pay for these features and the amounto market share our company can reasonably expect if we bring such a product to market. The MRD is used to make a financial case for the product; if we’re going to spend millions of dollars to build something, by golly we’ll need to see a return on that investment.

Functions and Features Come Into Play When Defining the Product
Once the market requirements have been identified and the ROI has been examined and approved, it is time to define what the actual product will do. The Product Definition Document, or PDD, is exactly that; a written definition of what features the product will have and how it will work. This document will serve as the blueprint for our product going forward.

A PDD is usually a “living document,” frequently revised during the development lifecycle withinput from the various groups that will work on the product. It will gain more detail as we wind our way through the development process. Larger companies have mastered this part of the process, while many smaller companies see it as needless paperwork.

Ironically, a PDD is of even greater importance to a smaller company. Like any blueprint or map, following a PDD will ensure as few distractions or “side trips” as possible and avoid escalating features that consume precious time and resources. A large company can sometimes afford to get sidetracked if there are enough resources available to straighten out the course. A small company, on the other hand, once sidetracked may never recover.

As part of the PDD, engineering involvement is required. A series of negotiations are required to ensure that the features being defined are practical, can be developed in time to market the product, and fit into the product’s cost target. While many companies define this as a linear process following a logical order of steps, it is much more of a collaborative effort. The end result should be a document that defines the product and a cost in time and development resources.

Engineers Develop the Prototype That Undergoes Internal Testing
Now that a picture of our product has emerged, it’s time to start the real work. Our engineering group will develop the product, both hardware and software, until a working prototype emerges. There will inevitably be surprises, both pleasant (a new chip or component allows greater performance for lower cost) and painful (a key feature will take longer or cost more to implement).

Some companies outsource the engineering and development of portions of their product lines (see “Weighing the Build vs. Buy Proposition” sidebar above), but the steps involved remain the same.

“We are the development team behind product names that are instantly recognizable,” states Greg Stone, marketing director for DynaColor USA in Irvine Calif. “Our OEM business is based on partnering with other companies and giving them exactly what they want. We’re completely committed to the success of the products we build, regardless of the name on the box.”

The Product Definition Document (PDD) is a written definition of what features a product will have and how it will work. The PDD serves as a blueprint for the product going forward.

The end result of this engineering process will ultimately be several fully functional and working prototypes. Once these are built, the internal test process begins. The testing process seems endless, and usually continues until well after the product has been released.

“With today’s software-based products, and especially with those that work over networks, the biggest challenge is product software and network testing,” explains Smith. “There are an endless combination of environments that products can be put in and ways they can be used. Identification and elimination of software bugs prior to launch is an art.” In fact, it is inevitable that some bugs or problems will not be discovered until after a product has been installed and is working for a while.

“Water intrusion problems on outdoor domes is a good example,” says Ed Hamilton, senior program manager for American Dynamics in Boca Raton, Fla.”Wit all of the different environments and installation techniques out there, it can be quite a while before we see a problem that can be replicated in
the lab. Solving the problem is often the easy part.”

Once testing of the prototype is complete, the design is generally reviewed again for manufacturability and compliance issues. Products that will be manufactured in large quantities will often undergo a factory launch process, where pilot builds are made to set up, train and test factory readiness.

Somewhere during this phase, a production quality version of the product will be built and distributed to a limited audience for final testing. This step is known as a “beta test” in the software world, but goes by a variety of names in our industry. Tech support will usually work with the product at this point, although many companies get them involved far earlier in the process.

Some manufacturers insert a final “product validation” step. This is an internal series of tests that verifies the customer experience is what the manufacturer expects. Packaging is evaluated, and a final pass is taken to ensure the required tools and accessories are included. Manuals, and other supplemental material and documentation are double checked for accuracy.

In this way, the entire “out of box” experience is examined for improvement opportunities.

Trade Shows Are Most Popular Venue to Launch New Products
Once our product is complete, it’s time to tell the world and make it available to our customers. Most manufacturers launch major products at one of two key industry events; the ISC West show in Las Vegas in the spring or the ASIS show in the fall (this year in Orlando, Fla., Sept. 12-15).

As part of the launch event, sales and technical support people will need to be trained (see sidebar on page 59 of May issue), marketing material and data sheets should be on hand and product should be available.

In actual practice, product availability is not usually what it is cracked up to be. With two annual launch periods, the date a product must be released is often set in stone, based upon the availability of an industry event to introduce the product.

Unfortunately, all of the variables in product development can cause the actual product shipment date to slip unpredictably. The product that is displayed at the launch event is often one of the working (or semi-working) prototypes, and it is not uncommon for a product to be launched twice (or even three times) before it is actually shipped.

Support Must Be Accounted for Long After Production Ceases
Many people don’t realize that a manufacturer’s obligation to a product does not end when the product is shipped, or even after it has been discontinued.

“We have systems out there that are more than 15 years old and are still going strong,” says Hamilton. “These must always be considered when looking at new products. Will our new dome cameras communicate with older controllers? Can we provide replacement parts for installed products once our inventory is depleted? Once you release a product, you own it for life, and that product may have a longer life than you ever thought possible.”

Not all of the steps included in this article are identified and followed in this order by all manufacturers, but most would agree with the basic sequence of events and the tasks required. Larger companies will have a team of people working on a product, each with separate and distinct duties. Smaller companies tend to combine tasks and have fewer people working on a given product. Either way, turning an idea into a finished, salable product is a complex process and a lot of work for all involved.

Most of us understand firsthand the costs associated with replacing a faulty or defective product. Repeated trips to the job site, frustrated customers, and projects that never seem to end are symptoms of products that have had a few corners cut in the development process. Although you may not be crazy about how long it takes to get a product to market, you’ll likely live with the delays if the end result is what you and your customer need.

Click Here to download this article in PDF Format

]]> http://www.tech-answers.com/published-articles/birth-of-a-security-product-security-sales-integration/feed/ 0 http://www.tech-answers.com/published-articles/consultants-time-to-end-the-confusion-security-sales-integration/ http://www.tech-answers.com/published-articles/consultants-time-to-end-the-confusion-security-sales-integration/#comments Mon, 01 Mar 2004 04:01:10 +0000 rdgrossman http://www.tech-answers.com/?p=298 Webster’s Dictionary defines a “consultant” as “a person who gives professional or expert advice.” But, with that definition, isn’t just about everyone a consultant? In our industry, organizations are quick to give their representatives titles that convey competence and expertise, which can be confusing to the end user.

How does the end user know who’s competent? With a sales engineer or systems architect, the answer is simple: Engineers and architects are degreed positions, so look for the diploma. But with consultants, it’s not as black and white.

Let’s create our own definition. We’ll stick with Webster as closely as we can: A consultant is a person who gives unbiased professional or expert advice and is beholden only to the person who has hired him.

Still, the advice given by a consultant varies, so let’s explore an advisor’s duties and responsibilities.

Consultants Help Make Decisions

Many vendors will provide design, engineering, installation and project management services as part of a “turn-key” solution. If you’ve selected such a vendor and are confident it will meet your needs, you do not need a consultant.

If there are several vendors involved, comparing their bids is much like comparing apples to oranges. If you believe that you can evaluate their offerings and select the one that best suits your needs, you’re acting as the consultant yourself and don’t need to hire outside help.
But there’s a difference between need and benefit: Many organizations find that there are tangible benefits, both financial and operational, in employing this outside expertise.

Consultants Often Act as Specifiers

A consultant is hired by end users to look at their specific concerns and apply the appropriate technology and operational procedures to accomplish their goals. The objective can be very specific or ethereal, but the end result is generally a specification that details how the problem will be solved. These specifications fall into two categories: functional and performance specifications.

A functional specification describes what a system will do. It is generic in nature and written to allow multiple vendors to apply their specific products. Often, it relies on the lowest common denominator to ensure wider participation between vendors, and may be accompanied by an approved vendor list.

A performance specification is more stringent and describes how the system will work. To accomplish this, a consultant generally has a spe¥cific system in mind, and while others may equal the performance, the criteria are much tighter. This type of specification selects a single vendor “or equal,” and is often the basis for a sole-source procurement agreement.

With either type, the consultant evaluates the options, discusses them with the client and – based on his opinion and expertise – designs a system around the customer’s needs or budget. Sometimes a manufacturer is favored because the consultant has had good experiences and often the installed equipment dictates the add-on products, but there should be no financial incentive for the consultant to choose a particular brand.

The consultant provides this specification in a format that may be sent to multiple vendors, ensuring a competitive bid process. While he helps evaluate the different proposed products to verify their suitability, he also explains the intangibles. Does the integrator have a history of success¥fully completing projects like the client’s? Will the manufacturer support the product for the life of the system? Does the product have a good track record?

“Theory cannot compensate for actual experience,” says Fred Zagurski, of Fred Zagurski Consultants. “Only a consultant from the ‘field’ will know what corners the bidders will try to shortcut, and (he) address these issues in their specifications.”

The consultant also acts as a representative during the construction and commissioning process. He ensures the installed system is the one specified, and will work through the many changes and add-ons that are inevitable side effects of the construction process. Often, a consultant will save his client more than his fees by ensuring the project stays on schedule and within budget.

Integrity, Experience Are Crucial

It’s clear there is no substitute for integrity and experience. To ensure a consultant’s independence, look for someone who is doing it for a living, and is not just “between jobs.” Look for experience with the type of project you are considering. And make sure he has been around long enough to have the reputation, industry contacts and people skills needed to smooth over the rough spots, should it come to that. Remember, your choice in consultant is a lot like a headache remedy – neither does you any good unless it takes away the pain.

Robert Grossman has spent more than 15 years in the industry and is president of R. Grossman and Associates (www.tech-answers.com),
a consulting group specializing in electronic security products and projects.
He can be reached at (609) 926-9264 or rdgrossman@securitysales.com

Security Sales & Integration 1 March 2004

Download this article in PDF format