Home > Manufacturers > A standard ain’t a standard unless it’s standard – and in physical security, it ain’t

A standard ain’t a standard unless it’s standard – and in physical security, it ain’t

I pumped a few gallons of Shell premium unleaded into my tank which was partially full of Mobil 93 octane. Got to my office and tuned the TV to CNN.  Watched it for awhile then slipped to Fox news.  Booted up the MacBook running Leopard and VMWare with Windows XP and surfed over to Google to read my RSS feeds from a dozen blogs and news sources.  I noticed the cleaners had loosened some plugs so I plugged my stereo system back in the wall.  That reminded me to use my Sprint cell phone to call the land line phones at the electronics store to see if the newest Blu-Ray readers are in stock.

That’s the thing about standards.  You hardly notice them till they’re absent.  Take Blu-ray.  Of the two competing standards in the high definition video format wars, I thought HD-DVD was going to win.  DVDs are awesome, but high definition DVD seemed way better.  But I wasn’t confident enough to plop down 400 bucks until the vendors fought it out amongst themselves.  For awhile I thought about grabbing that Samsung player that played both video formats, HD DVD and Blu-ray, thinking that Samsung was creating an integrated environment by supporting both.  Then I looked at the price tag and saw it selling for nearly twice the price of a standard Blu-ray box.  Integration sure can cost a lot.

I just referred to Blu-ray and HD-DVD as standards.  I should have said proposed standards.  That’s because a standard is only a standard if it’s standard.  Er…you know what I mean.  Two groups worked out a new format for all music and video disks, but they weren’t identical.  It took a consensus of distributors and customers to decide which would become the actual standard of choice.

In the security industry we talk about standards all the time.  H.264 looks like it will be the compression standard of choice for squishing video into tight streams to fit on our overloaded networks.  IP v6 is poised to be the protocol to handle the exponentially growing traffic on our networks.  But an obviously missing standard in our industry is messaging.  Remarkably, there is no standard way to get a message from this access control server, or that video analytics processor to this event management correlation engine.  Blows my mind. 

This is not rocket science.  You decide on a delivery platform, like XML, and a format of headers and tags for different classes of information, and everyone starts using it.  Creating the standard is easy.  Desiring to create a standard, well, that’s the sticky part.  Ask some of the big named vendors – especially the ones touting their use of Microsoft, Oracle, and other IT standards based products – to describe their approach to standard messaging and they’ll happily tell you about their application programmer interface (API). 

A vendor told me the other day that his access control solution was “totally open.”  When I asked what he meant he told me he offers an SDK to qualified partners.  I don’t know what some of these people are smoking, but an API is not a standard.  Neither is an SDK (a software developer’s toolkit).    APIs and toolkits are proprietary.  They are like secret invitations to the private club.  It’s like those shifty car dealers offering 0% financing to qualifying buyers.  That “qualifying” bit keeps it exclusive.

Interoperability is really the key for being open or standards based.  But that’s only a half step.  Sure my product can be interoperable with anybody else’s, but as soon as one vendor in the infrastructure changes something, everyone has to change.  The whole point of standards is that once you embrace the standard, you are guaranteeing a higher level of interoperability, rather than interoperability that is frozen in time.  There’s another catch.  Just because my product is standards based, and so is yours, it doesn’t mean our products are interoperable.  For example, if I encapsulate my video in RDP and you encapsulate yours in UDP, we’re still sunk.  We’d need some middleware to get the two systems to work together. 

Clearly XML is a popular way to tag and share information between multiple systems.   XML is not exactly a standard – it’s merely a schema, a template, for presenting information – but it’s close enough.  It could easily serve as the perfect foundation for sharing information.  Next, product makers will have to decide which XML tags to use and what classes of information to associate with the tags.  If XML isn’t the preferred platform, then let’s pick SNMP or something already! 

All I’m saying is that you, the end users, security executives buying and using security technologies, will be able to have more efficient, effective, flexible and value-creating security architectures if the vendors would get out of their good ol’ boy mentality and allow new software and hardware to interoperate easily.  Standards are the most effective path to that interoperability.  We want to evolve to a plug n play environment.  Unfortunately the closest I’ve seen so far is plug n pray. Most integrators and vendors don’t even achieve that, however, preferring good ol’ fashioned plug n pay.

Well, gotta run to the store and pick up my Blu-ray player.  Hmmm, but will it play my home video DVDs?

Categories: Manufacturers
  1. March 26, 2008 at 12:10 pm

    Security equipment manufacturers have very little incentive to adopt open standards. Most manufacturers like to think of themselves as “total solutions providers” and want the customer to buy all their systems (access control, CCTV, etc.) from a single source rather than to mix and match products from different manufacturers.
    With the advent of the “super conglomerates” like GE Security and Tyco, this situation has gotten worse rather than better. The very reason that these corporations are acquiring manufacturers in all product categories is so that marketing synergy can be achieved between the product lines. While many of these companies pay lip service to “open standards”, the truth is that this concept is in direct conflict with what the manufacturers are trying to achieve from a marketing standpoint.
    As a consultant, the systems integration issue is something I have been fighting for over 20 years. The challenges are rarely technical; they usually involve politics and marketing considerations and the inability of various corporate entities to play well with one another.
    I would love to see a set of open standards for interoperability in the physical security industry, but doubt I will see this in my lifetime.
    I hope I am proved wrong…

  2. John Honovich
    March 26, 2008 at 12:56 pm

    Hi Steve, Hi Michael,
    I agree with both of you that manufactures are usually motivated to build closed solutions.
    However, a legitimate motivation exists to break standards.
    Significant customer value can be created by engineering products that break standards. This creates a tension between interoperability and performance. As customers generally want both, often one of the two has to suffer. The plug and play Steve mentions is often in conflict with performance maximization.
    2 examples:
    1. Steve mentions H.264 video codec. While I agree that momentum is building around H.264, it is not uncommon to find manufacturers to deviate from strict conformance to H.264. Some may be doing this for greed and lock-in but others are doing this to increase storage efficiency. Because surveillance video exhibits certain regular qualities, optimizations can be made to a standards based video codec to increase performance for that application. Now, from a customer perspective, the question can be “Do you want interoperable video or decreasing your video storage costs in half?” This can be a tough business decision.
    2. Let’s look at video analytics and using XML for a standards based sharing of information between systems. Because video analytics are still evolving, standards can constrict the ability to innovate. Myriad situations are arising where different analytics need to be used, new analytics need to be introduced, analytic or biometric metadata differs, analytics need to handle certain bandwidth conditions, etc. Standards will restrict the ability to innovate or optimize. This creates situations where the customer is choosing between an interoperable solution and one that performs better for their specific conditions.
    I do think standards bring benefits and many vendors resist standards to the detriment of their customers yet we should be cognizant of the benefits that deviations can bring.
    Finally, Steve, as for your story about the access control vendor who is “totally open”, I hear the same story all the time. I suspect a lot of this is technological ignorance rather than malice. That being said, claiming to be totally open may be a great marketing line but is almost always operationally wrong.
    Security vendors do not and should not offer “totally open” solutions. Being somewhat closed is generally beneficial to customers. Unlike using Facebook’s or Flickr’s API, if a problem occurs in the integration of your systems, you have a real business problem not just an inability to play games or view your friend’s photos. Restricting access to ensure testing and compatability of systems helps eliminate very painful headaches in the field.
    Thanks for starting this conversation.

  3. Ringo
    March 26, 2008 at 8:15 pm

    What a great conversation starter, and great comments following. John makes some good points in his latest comments without a doubt.
    As for the ‘totally open’ access control solution. The most flexible and open that I’ve seen on the market is the S2 Security platform. They use XML. They have an open API – no private clubs to join… There’s still secret sauce in every sdk or api, that’ll always be the case and it always should be in the physical security market. Additionally with S2, they integrate with a lot of other ‘best in breed’ solutions like ONSSI or Milestone on the IP-video side, and imprivata (like some other companies) on the logical side and don’t push a ‘branded solution’. I’m not touting them singularly, but their message is good and is becoming more and more widely accepted.
    The problem with the conglomerates is that they (as Michael) says, push their whole comingled brand at you. Most innovative technology companies in security’s biggest challenge is Honeywell or GE’s marketing dollars. But look at poorly they’ve moved their platforms up the technology curve… What does that tell you? They are just marketing companies, and that’s why the 3VR’s, the S2’s, and the ONSSI’s have a really good shot of being the next ‘big things.’ It’s funny, while on the topic of the conglomerates, that to add insult to injury, companies like Lenel are witnessing mass exoduses from their former Sr. Executives allowing the conglomerates yet another shot to brand, and package, themselves into a mediocre product offering…
    Sheesh! Every hurdle is someone else’s opportunities. I believe a lot of progress is finally being made, but there is a long way to go… This is one of the best threads I’ve seen on here in a long time! Thanks!

  4. March 27, 2008 at 7:18 am

    Well put Steve!

  5. March 27, 2008 at 12:53 pm

    I really appreciate the conversation, guys. Keep it going!

  6. Ringo
    March 27, 2008 at 3:28 pm

    On this topic, has anyone else heard that Mercury is in serious discussions to sell? What would this do to the seemingly ‘openness’ involved with using their panels?
    I don’t subscribe to this as being a good idea in the first place, but clearly others do… So, any comments on this? Could make more waves in the industry if true. Tis speculation though.
    Anyway, the quicker top-tier manufacturers interoperate with each other, the better. Save nothing about keeping up these integrations, but the fact that some ARE indeed good is great for the industry. Much better than buying a branded end-to-end solution from say GE or Honeywell… All your guaranteed there is a name, and of course marketing dollars 🙂

  7. George
    March 28, 2008 at 11:03 am

    Some of the comments seem to indicate it’s preferable that access control panel protocols not be publicly documented. What purpose does this serve other than to limit customer options?

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: