“Me Too” Products
Being wise about the products you present to end users
- By Ian Johnston
- Dec 01, 2014
For manufacturers to play within the commodity space, they need to
provide the most features, ease-of-use and the best reliability, camera
versus camera. If that is accomplished at the going price, you have
everything you need to compete in that arena.
Leadership comes from recognizing the specific needs of an end
user and innovating better ways to meet those needs affordably. An example of potential
industry leadership is the practical application of what have become known
as “edge surveillance products.”
Understanding “Edge”
I think that my definition and concept of edge is very different than anyone else. I
loathe the phrase “edge now;” it’s been perverted and abused into being something
that is so constrained and limiting that it’s become useless as a definition of what
I think edge can be.
The current structure of how IP video is generated, managed and consumed is
backwards and behind the curve when viewed in context to other analog, digital
transitions. All the security industry has created thus far is a faster, more expensive
VCR and a higher resolution CCTV camera. The paradigm of how everything
works and knits together still intrinsically follows that same tired, wholly-broken
1970s model. In order to progress and step into the 21st century, this must stop.
A camera is simply a sensor that collects video, but a modern IP camera has a
full 32-bit server with more memory and computing power than the personal computer
I had when I was studying at a university. Imagine if we said that a mobile
phone could only be used for phone calls simply because it was called a phone?
The same concept and restriction is being pushed onto cameras.
Edge, for me, means autonomy. Personally, I prefer the term “hive” rather than
edge since it has a better connotation of a system of individual elements that are
all working autonomously, yet collectively, to get a job done. Please note that my
vision is impossible if I’m constrained to just a camera; the right VMS is a canvas
on which to paint. My concept may still be a bit too far ahead of the curve in terms
of what the security industry can digest, so it’s best to lay out the edge in steps and
as a roadmap of what will come:
Storage. If a camera needs storage for the video it is collecting, there are many
assets it can use. The one that has been pushed by most vendors today is using local
or edge storage in the form of an SD card, or in our case, multiple SD cards.
That’s great, especially given the fact that we at ISD/Digital Watchdog (ISD/DW)
can put up to a full Terabyte of storage on a camera and that’s only one possible
destination. Other popular destinations would be a conventional PC server, nosql
ORACLE database, NAS box or Amazon EC3 cloud storage. Fundamentally, it
doesn’t matter what or where it is; what does matter is the size of the data that
you’re trying to move around and making smart choices about bandwidth management.
Data shouldn’t be constrained to a single repository or a single function,
and all devices need to work together to ensure that everything is taken care of and
that no single entity fails or is a point of failure.
One of the jobs of a camera is to make sure that the video it is generating gets
stored. It should be empowered to use any asset that it has access to in order to
fulfill that role. An edge camera sending video to a standard PC is perfectly legitimate,
but if that connection fails, it has an obligation to switch to its local repository. If that fills up or breaks, then it
should switch to another camera and
use its SD card instead. Arguably, if
the device is in a critical area, it should
be doing this all the time and sending
the video to all destinations simultaneously.
It has the responsibility of checking
in with its hive mates periodically to
make sure they aren’t having problems
and are still visible on the network.
The point is that cameras should
no longer be devices that blindly spew
out video in a fire-and-forget mechanism.
Instead, they should be given the
responsibility to ensure that their payload
is delivered reliably. Think more
of an asynchronous, peer-to-peer architecture
where cameras and servers
have equal footing and a responsibility
to cry if any of them are unhealthy.
None of that exists today, except in
our lab.
“Army-of-one” model. All implementations
for the moment are in a
relatively conservative manner, but that
will blossom and flourish with better
IPVMS platforms. The camera hosts
some form of the server on itself and
uses local storage to write video. Current
systems have this as an army of
one, meaning there’s no interaction
between the cameras, nor is there any
interaction with a conventional server.
The army-of-one issue is where most
consumers have a significant amount of
heartburn about deploying edge:
- What happens if the camera gets stolen?
- What happens if the SD card breaks?
- What happens if things stop?
- How do I know that it failed if the
camera fails silently?
All are good questions and consumers
are smart to think about such things,
except for the fact that if a camera is replaced
with a server and it breaks, now
multiple cameras aren’t recording.
While it’s limited, this model is useful
for applications where you don’t
have the ability to have a relatively high
power server running in a remote installation.
Construction site monitoring or
remote/covert surveillance are great applications.
The fact that ISD/DW cameras
are low power (2 watts) makes it
easy to deploy cameras using battery/
solar power. These days, a 64GB card
can provide almost a week of storage,
if recorded on motion.
A properly designed edge system is
more scalable, fault-tolerant and has the
ability to adapt to other requirements. It
doesn’t have to be more expensive than
a conventional “head only” system since
most of the concepts I’m talking about
are largely software based, using a different
paradigm of how the security system
gets deployed.
Applications. This is where edge
cameras have an immediate advantage
over their acrophobic brethren. It is
summed up with one word: scalability.
Analytics have traditionally been
run on conventional PC servers and
have had a tendency to over promise
and under deliver. Smart folks have
long figured out how to use some clever
math to determine what the camera is
looking at. They’re usually prototyping
with a single camera running on a
big iron PC with tons of RAM. Those
same people demo it to their sales team
who immediately say, “Wow! I can sell
that!” Then, they get venture capital funds to sell it to the world. Everyone’s
happy; they do demos to potential customers
and install test deployments.
All is good. The challenge comes when
their customer wants to use more than
a few cameras on the same PC. Here is
the awkward conversation about having
to buy more big iron servers; it’s just
not scalable.
As a good friend of mine, who lead
the engineering team of a leading analytics
company, said, “You can’t go
out of business fast enough being an
analytics company.” Most have become
VMS companies with optional analytics
to keep alive the dream of what they
started. The critical flaw, with the possible
exception of a select few companies:
Analytics companies all wanted to
run on generic cameras, hoping that the
various camera companies would help
sell their solution. It never happens.
Bad things happen.
Change the Rules
The consumer electronics industry has
led to some stunning innovations and
advancements in mobile computing.
The fact that you can play Angry Birds
on your phone is a prime example. As
for the security industry, as a whole,
they’re focusing on making the camera
equivalent of a No. 2 pencil, so they’re
unwilling to put any meaningful investment
of technology into the cameras.
This means they can’t do anything intelligent
at the edge and no one is able
to escape the black hole that is commoditization
and consolidation.
With modern CPUs that are targeted
for mobile devices, it is possible
to run meaningful analytics at the edge.
Right now, business analytics and intelligence
for marketing applications are
all the rage.
We announced at the 2014 ISC West
show a partnership with Prism Skylabs,
and at the ASIS 2014 show, deployment
with their analytic fully running inside
our next generation cameras without
any compromises. Why is this important?
Why do I feel this is critical to
their success? Scalability and the elimination
of servers.
With the kind of deployments I have
described, every camera has the processing
power it needs to be successful.
Whether deploying three or 3,000 cameras,
it doesn’t matter. It’s scalable, deterministic
and eliminates the need for
expensive servers. It is a win for everyone,
even IT departments that tend to
be suspicious of any third-party servers
installed on their networks. They are
correct to be nervous, given the threat
of malware that inevitably gets uploaded,
not to mention inappropriate activity
that often coincides with a PC that
has a screen, keyboard and network
connection.
The camera is an appliance. It has
everything it needs to automatically
configure and deploy itself when attached
to the network by integrators.
That user experience can be simplified
to a “lick-and-stick,”
analog-like deployment.
It is simplicity
that just works.
This article originally appeared in the December 2014 issue of Security Today.