Poor OSDP Usage Statistics 2019

By Brian Rhodes, Published Jul 09, 2019, 10:33am EDT

OSDP certainly offers advantages over decades-old Wiegand (see our OSDP Access Control Guide) but new IPVM statistics show that usage of OSDP, even in new readers, is extremely low.

Inside this report, we examine the trends and the key reasons for and against the credential communication protocol.

Results **********

*** ************ ******** ** integrators ******** **** '*****' or ****** *** ****.

****, ******* ***** ******** as * *********** ** Wiegand, **% ** *********** answered **** *** ******* more **** **** *** OSDP:

**** *** ****** ******* as ******* *** **** adoption:

  • **** *** ****** ****** from ********* *** ** not ********* ** *********** outside ** ****-********/ ********** markets.
  • **********'* ********* ****** ******* do *** ******* ****.
  • **** ***** **** **** Wiegand *** *** ******** are ******* ** **** a ******.
  • ********* *** ***-***** ***** do *** ********** ** aren't ******** **** ****.

** ***** **** ** those **** ** ******** sections **** ********** ***** comments *****.

OSDP ******* *****

******, ******* **** ******** is **** ******, *** possibility ** ****** ********* may ** * ********** concern.

****** ****'* **** ******* is **** *** ********* proponent, *********** ******** *********** (***), ** *** **** known ***** *** ***** and ***** *********** **** other ******** ****** *********, ******* ** ****, Sony, *** ***** *** for ***** ************.

**** *** *********** *******, OSDP ** ** **************** standard ******* ******* *** controllers. *******, **** ****** many ************ **** ************* communication, '****** *******' **********, and *-*** ********* ******* not ********* **** *******.

*******, ******* *** **********, integrator ******** **** ** clear **** **** ******** is *** * **** thing ** ******, *** when ** **** **** place ** ******* ******, in ******** ******** ** the ****** *** ********* of *******'* ******** ***** are *** *********** * powerful ****** *** ********.

For ****, **** *** ****

*** **** ******** ** integrators ******** **** ****** never *** **** *** stick **** ******* *** to **** ** ******, lack ** ********* *******, and ** ************** ********* it:

  • "**** **** **** ****. Our ******** *****'* ******** the ****** ***. **'** most ******** **** *******."
  • "*%, *** ** **** of ******** ** ** and *** **** ** customers ********** **."
  • "****, ** ******"
  • "*%. *** ****** *** our ********* ***** ******* is **** ********."
  • "****. **** *** ******** to *** **** *******."
  • "****** ****** ** *** being **** ** *****/*** solutions. ******* ********** ********* as *** ***** *** not **********."
  • "*%. ******** *** ******** we *** ********** ******* it (***), ** ** not ******* **** ********."
  • "*% ** *** *** buying **** ***** ** readers ***."
  • "*% ** **** *****'* explored **** ******."
  • "*% *** **** **** ended ********* **** ******* to *** ******** ****** for *** *** ********** existing ******* *** ******"
  • "*** ** *** ***** written ** ***********."
  • "*%. ** ** *** important ** **."
  • "****, ** ***'* *** any **** ****** *** our ****** *******, ** are ******* ******* ** Bit ******* *** *** access ******* ********."
  • "*% ** *** *** been ********** ** *** moment."
  • "*. ** *** *** come **."
  • "*%-*** ****** ********/*********/******** ***"

Not ********* ** ****** *******

** **** ** ***** that **** ** ****** not ****** ********* ** Wiegand ** ****** *********.

***** *** ******* ****** of************* ********** **** ** growing, ***** *** ***** significant **** ** ******* with ******* ****** ***** limited ** *******:

  • "*% *** ********* ** our *** ** ****** and *** ***** ** all."
  • "****. ** ****** *** TDSi *** ****** *********."
  • "*% ** ****** ** AMAG *** *** ***** don't ******* **. ** are ******* ***** ** roll ** *** ** a *** *** ********* on *** *** ***** new *****."
  • "***** **** ******* * do ******* **** **** is ********* *** *** Security *** **************** ** Access ******* *******. *** main ************ * *** is ****** *** **** only ******* *******."
  • "****. *** ****** ******* do *** ***** ** end ** *** ********."
  • "** *** * ***** single ******* ** ****** 1000 ******* **** **** specifically ******** **** **** but ***** *** ***% deploy **** ***** ****** phases ******* *** ***********. As * ******** ** try ** ******* **** on ****** ***** ********."
  • "**** ******* ** *** siemens **********"
  • "*% ******* **** ****** don't ******* ****."
  • "*% *** *** **** not **** **** * product ***. ******."
  • "*. ****** ******* ******* we *** **** *** support ****."
  • "******* ** ***** ********* in *** ********. ** is **** * ****** of ***********."
  • "*** **** **** *** only *** **** ******* for ***** * ****** - ** ****** ****** uptake ** *** **** future."
  • "**'** ****** ***** ** new *****, *** ******** customer ******* ***** *** weigand ** */**"

** ****, **** ****** and ********** **** ******* OSDP ** ** ***********, a *** ***** ** discuss ** ******* ****** ******* *****.

Do *** ********** ****

******* ***** ** *** fact **** *** *****, access *******, *** ********** do *** ********** *** advantage ** ****. *** lack ** ************* ** a ******* ** ********** the ******** ** ******* security ***** ** ***** it ** ******* *********** between ****** *** **********.

*** ******* ******** *********** this:

***** **% [*** ****]. We *** ** ****** new ******* **** **** security ** **** ** a ******* ********, ****** many ** *** ********* are *** ** ********** in ** ****** ** make ** ********* ** their ****. ** **** had **** *** ******** concerned ***** *** ********** between *** ****** & controller. **** ** *** customers ** *** **** that **** ** ****** is ******.

*******, **** ********* *** the ******* ****** **** cited:

  • "* ***** *** ** is *** ***** **** because ** ********. **** few **** ***** ** and/or ********** *** ********. And **** ********* ***'* know ***** ** ** don't **** **."
  • "*** ****** ******** *** the ***********, *** ****** information *** ********* ** change ***** ******. *******, this ** * **** for ** **** *** next ****."
  • "[*** **] ******* *** not ********** ***. ********* over ****** *** **************. Wiegand ***** ********."
  • "*** **** ****** *********** aren't ********** ** **** much."
  • "** ** *** ********* people *** ******** **** yet *** * ***** we ****** **** **** it ****."
  • "*** ********* **** ******* systems **** ** *** expanding *** ******* *** OSDP ** *** * requirement ***. **** **** to ** ** ** some ***** ******."
  • "** **** *** *** implement ***** ****. *** reason ** **** ******* that ** **** *** still *** ***** *** open ********. ***** ** still * *** ** educating *** ******."
  • "** **** ******* ***** the ******* ************* ***** this **** *** ** informing *********"
  • "*********** ** ***** *** not *****. **** ** sell ** ** ********. Sad **** *********** *****'* even **** **** **** is"
  • "*** ****** ********* ***** OSDP."

*** ***** ******* ** the ******* ********* *** features ** ****, **** published**** ****** ******* ******* ******* *** ***** differences ******** ** *******.

Extra ****, ******* *******

******* ************ *** ** the **** **** ********** often **** **** **** their ******* ************, **** before *********** **** ********** labor (**: ****** ******* costs) *** ***** ****** to ***** *** ******** for ***, *** *** for ******* *******:

  • "** **** *****, *** additional **** ** **** readers ***'* **** ** being ***** *** ********** security ** ********."
  • "**%, ******** ** ********* have ********* *** ***** cost ******."
  • "************ ******** **** *** customers. ** ******* *** show *** ******** ** utilizing ** *** ******* but *** ********** ** OSDP ******** ****** *** bottom **** ************* ** larger *******."
  • "* ***’* ***** * have *** **** *** OSDP. ****** **** ******* and ******* **** ** our ******* *** ******** customer *** ***** ****** not ** ************ ***** or ****** *** ******* equipment."
  • "**** ** *** ******* are **** ********** ** existing ******* ** ********* where ****** ** ********** and ** **** ** maintain **********. ******** *** the **** ********."
  • "**% ** *** *** install **** *** **** based ******* *** ** higher **** ** **** readers *** ******** ********* towards ******** **** **** budget."
  • "** **** ***** ********* readers **** **** ****. We *** ***** ** the ********** *** *** you ***** *** ** but ** **** **** not *** * *** demand **** ********* *** us ** ** *** of *** *** ** start ***** ** ** training *** *********** *** engineers. ** ***** **** this ******* ** *** huge *** *********. ** are ******* **** ****** to *** ********* ** stop ***** ****** *******."
  • "****. *** ** * good ********. *** **** of *** **********. ***** able ** ***** ***** readers ***'* ******* ***** you **** ** *** all *** ***** ****** to *** ****."
  • "********* ****** ** **** money *** *** *******."

***** *** **** ********** is ********** ** *** some *******, **** ************* like *** *** ******* essentially ******** *** **** for ****** ******, ***** manufacturers ****** * ******* for ****.

*** *******, ** ************ **** ****** ****** Test, *** **** ******* we ****** **** ~**% more **** *** ********** Wiegand *****.

Heavy **** *****

*** ******* ********* ******** or **** **** ********, they ***** ********* ***** it ** ******** ** 'high ********' *************** ********** *** ************* systems.

************, ******** ********* ** government***** ********* ************ ******* **** *** compose *** **** ** their *************** ******* ** 'regular' ********** ******:

  • "** **** ***** ** OSDP ** *** *******. First, ** ** **** secure. ***, *** *** optical ****** ** ******* by ******* ******* *** additional *******. ***, ** are ********* * ******* government ********** *** **** is ******** *** ***** compliance, ** ***** ** using **** ** *** show **** *** ******** is ****** **** ******/******** in *** ***** *********."
  • "**** *** ****** ***** like **** *******. **** are ***** ***** *******."
  • "** **** **** ***** a ***** ********** ************ that ******** ****-** **********. This ******** *** *** of ****."
  • "******** ** *** ******* concerned ***** ******* ** Prox *****. ******* ****** educated *** **** *** encryption *** ******** ******** offered ** ****."
  • "***%. **'* **** **** secure."
  • "** *** ** *** Fed *** ********* *** spec *** ***********"

SIA ********

** ****** ***** ******* with ***, *** ******** group ************ ****, ****** '**** ***** are *** *** *********** members ****** ** ******* OSDP *** **** *******?' and '**** **** *** suggest *** *********** ** educate ***** ********* ** OSDP?'

**** ************ *** *******, emphasizing **** **** ********* is * ********* *** group ** ********* ******* to *******:

*** ********** *** **** for **** ********* ** both *** ********** *** implementation ** *** *** OSDP *************.

*** **** ******* *****, and *** ****** ********* have ***** ******** ***** to ******** *** ****** of **** ********* ****** the ****** ******** ********* (manufacturers, ***********, *********** *** practitioners).

*** *** ****** ********* have ********* *** ****** individually **** *** **** 18 ****** ** ******** OSDP ********* ******* ********, live ******** ** ********** and ***********, *** ***** platforms.

*** *** ********* *** SIA **** **** ****, designed ** **** **-*****, hands-on **** ********* ** integrators, ************* *** ************ trainers. *** **** **** Camp **** ** ********* for ***** ******* **** at *** *******, *** the *** **** **** Camp ****** **** ** co-located ********** **** * number ** ******** ****** throughout *** **** ** the **** *** ****.

*** ** **** ** the ******* ** ********** fact ******, **** *** free ***** ************* ****** designed ** **** ************ with *** ****** *********** between ********* **** *** Weigand.

***** ******* *** ** addition ** *** ****** SIA *********** *** ******* events ** *** **** that ******** *** ******** of *** **** *** promote *** *** ** sharing *** **** ************** experiences ** *** ********* that **** ****** **** as ***** ****** ******* solution.

*******, *** ****** **** many '****' ********* ******* are ***** ** ***********, and ***~$*** **** **** *********** **** ** *** a ********* ****** *** many ****** ********** *** specifiers.

*******, ** ***** ** become **** **** * fringe ****** *** ******, OSDP ********** **** ** become **** ********* ** communicating *** ********* ****** specifiers ** *** ********** and ********* ***************.

Comments (25)

Undisclosed #1

07/09/19 03:57pm

Great writeup! 

Only people who work in specific verticals seem to be comfortable with the nuances that exist with OSDP.  This permeates beyond only integrators and specifiers:  even cable manufacturers seem to struggle with a composite access control cable that doesn't have a 22/6 shielded cable.

The risk in broad adoption currently lies with the integrator.   Adopting the change in standards becomes an education effort for a sales team, an engineering team but also every technician.   Integrators run risks in labor overage when working within the unknown - and right now the end users are not providing the demand for them to do so.

I had to become comfortable on it by cutting my own teeth.  Integrators are not going to risk the extra labor in implementing a new technology when the end user doesn't feel like they have much ROI.  Yes, it is the same cost... but not when integrators need to fork over extra labor to learn on the job.

Agree: 4
Disagree
Informative: 1
Unhelpful
Funny

Undisclosed #2

In reply to Undisclosed #1 | 07/09/19 05:51pm

My 2¢ is that OSDP should be replaced by ethernet technology, look at all the other devices that are PoE. The security manufacturing industry should be ashamed for not evolving with common technologies. Card readers just transmit simple data for authentication, it is a really dumb device when you break it down. Those that think 'the network' is vulnerable by using PoE readers are the ones that need the 'extra labor' to learn why this is not true and again, security manufacturers should/can develop additional advances on securing physical network EOL connections. Such as simple devices that optically severs the data connection if the card reader does not authenticate itself with the switch, has a tamper alarm and last lost power for any reason. Naturally this device would reside as close to the switch source, or not.

Speaking of card readers, how much do they cost to make? $20?  $35? Think of those cheap Honeywell OP10 readers, well they work right? Compare that to an HID Seos reader with blue tooth, NFC, cool blue LED, what do those go for? (keypad version, pivclass version  w/PAM -> lol).

Enough ranting. HID...you need to integrate a 720p or > camera into your readers, go full standard ethernet. Connection to PACS can be private network(common for cameras). Last, since the reader is now a camera just have the VMS verify the authentication with the PACS. Boom now you can sell a IP-RDR-CAM license in your unified system...err Genetec(sigh). Instead of having a back end system authenticate credentials just have the reader used the card holders phone to push a third token to the net for authentication...err Verizon here you can jump in on the game as well. The HID camera is used for facial recognition, QR codes that kind of stuff, need a keypad reader? Well the reader can ping the user on the phone to verify a PIN or simply scan a QR code on the reader itself.

Someone needs to get on top of all this aging low security technology. Tyco? UTC? ….taps finger.

Thanks for bringing up the report, I just do not think OSDP is the right application. I also despise Wiegand but oh well, I just sit here watching all the dinosaurs on parade #VerkadaPFFFFT

Agree: 4
Disagree
Informative
Unhelpful
Funny: 2
Avatar

Jacob Hengel

YourSix | In reply to Undisclosed #2 | 07/10/19 01:02pm

Axis' A8207 is a combined reader/pin/IP camera that even adds in intercom functionality via SIP. Even further to your point, the device can be a poe reader but it does have to be connected to an Axis controller to serve that function out of the box since that uses VAPIX. Other integrations seem feasible but limitations would really be on the controller / software side in that mix. Just wanted to outline that there are innovative companies bringing this type of technology out exactly as you explained it.

Disclosure: not an Axis employee, but do help integrators bring their devices into the cloud with partners.

Agree
Disagree
Informative: 1
Unhelpful
Funny

Undisclosed

In reply to Jacob Hengel | 07/10/19 04:38pm

...and the whole "database lives in the box on the insecure side of the door" thing is not an issue, i take it.

Agree
Disagree
Informative
Unhelpful
Funny
Avatar

Jacob Hengel

YourSix | In reply to Undisclosed | 07/10/19 08:36pm

This device is not the controller. It does function as a reader & intercom & IP camera, but communicates with a separate controller.

Agree
Disagree
Informative
Unhelpful
Funny
Avatar

Rick Caruthers

Galaxy Control Systems
In reply to Undisclosed #2 | 07/10/19 01:28pm

UD#2 - You raise some good points in your comment and there certainly are many areas of improvements to be made in this section of our industry.  But the one thing that you must understand is that many of the companies that claim to be "Access Control Manufacturers" are in fact nothing more than software developers and build nothing themselves. That is the new trend these days, pick a OEM hardware company, build software around whatever they allow within the confines of the SDK/API and hit the market. 

Agree: 3
Disagree
Informative
Unhelpful
Funny
Avatar

Michael Votaw

In reply to Rick Caruthers | 07/10/19 02:26pm

Spot on Rick.  Seeing the trend of the television.  Few years back Westinghouse was the largest TV manufacturer in the world I believe.  Actually made nothing.  Sales office and some engineers.  Deal with it every day when I have to wait for engineering to talk to engineering to try and solve issues on OEM hardware they don't make and software they design, but don't write.   Been 4 months on one issue now.

Getting very old in my opinion.  Lots of wasted time and manpower for all involved and unfair to the customer who purchased a product they expect to work.  Oh wait, that's been Microsoft's strategy for years.  It's good enough.  Sorry about the big IT bill to keep our product working. 

There appears to be little to no real innovation, just marketing ploys, feature creep and unneeded complexity.

OSDP has some great benefits, but until it's universal and adopted we are only installing when requested by the end user. 

Really, do we need yet another product running firmware that can have bugs, needs updated and can add future features.  Cool, but practical or cost effective?

Agree
Disagree
Informative
Unhelpful
Funny

Undisclosed

In reply to Undisclosed #2 | 07/10/19 04:37pm

There's FUD around IP-at-the-door.  People mangle it into "unprotected corporate network traffic visible on the outside of the building."  Also, your average reader vendor barely spending enough money on a processor that can run AES has trouble motivating themselves to add ethernet to a new board.  (While that whole Iot thing rages in the background?)

I think that IP at the door, connected into a sensibly designed network infrastructure that likely uses segmentation and firewalls and data diodes and all that stuff, sounds completely reasonable to your average network-literate buyer of infrastructure...

Agree: 1
Disagree
Informative
Unhelpful
Funny
Avatar

Scott Fischer

Lorica Consulting LLC
IPVMU Certified | 07/09/19 06:24pm

Thanks for posting!  As a consultant and end-user, I have spec'd OSDP v2 (with SCP enabled!) in multiple access control installations since mid-2018.  We have used three different integrators; however, I have yet to see anyone successfully set up the system to include properly configuring OSDP.  We have worked closely with the manufacturers to develop compatible specifications and even included manufacturer-provided part numbers to facilitate ordering the correct equipment.  

We have been told "the wrong part was shipped", "the technician was not familiar with the technology and threw away a critical piece", "the reader is bad", and "it is set up correctly" (even though the system clearly shows OSDP and/or SCP is not active). 

With these issues, OSDP installations must be frustrating for the integrators since they have to re-order parts, send technicians back out to the site, and overall significantly increase their costs in an effort to get the systems running.  It is also extremely frustrating for an end-user who wants to install a system that will be able to take advantage new capabilities as manufacturers continue improving their implementation of OSDP.

Agree: 3
Disagree
Informative: 5
Unhelpful
Funny
Avatar

Brian Rhodes

IPVMU Certified | In reply to Scott Fischer | 07/09/19 06:39pm

Thanks for the comment!

The end-to-end configuration between readers and controllers for OSDP is clearly a weakness compared to the default 'plug & play' nature of Wiegand.  I think there's an opportunity for vendors to automate the process via software, but it will mean abandoning Wiegand as the default.

That's where it gets troubling.  Incumbents like HID are averse to abandoning insecure, fully hackable 125 kHz credentials (We've even published on this, see: HID: Stop Selling Cracked 125 kHz Credentials), but there is little interest in moving away.

So, like 125 kHz, Wiegand looks here to stay, and OSDP risks being a fringe unless more significant steps are taken by SIA and OSDP vendors.

Agree: 3
Disagree
Informative
Unhelpful
Funny

Undisclosed

In reply to Scott Fischer | 07/10/19 04:42pm

Installing OSDP does in fact require ording the correct parts, providing proper tools documentation and configuration details, and informing the person driving the truck to the jobsite what the plan is.  Integrators do seem to sometimes fail on this with OSDP.  That's not a protocol issue, that's a "how far in skillset from trunkslammer status" is your deployment team.  You trust these people to install LPR, and Facial Recognition, and Fire Alarm systems and they can't order proper parts?  (Or are trained to give that excuse at least.)  And you treat this vendor as a Trusted Advisor?

Agree: 3
Disagree
Informative
Unhelpful
Funny

Undisclosed Integrator #3

07/09/19 07:58pm

What is it with osdp that makes it so much more labor intensive to setup? 

Agree
Disagree
Informative
Unhelpful
Funny
Avatar

Brian Rhodes

IPVMU Certified | In reply to Undisclosed Integrator #3 | 07/09/19 08:06pm

It isn't significant. Nominally, it is wiring it to controllers using different ports (usually serial reader controller ports) and then configuring the controller/access management system to communicate with the reader using OSDP. Usually this requires logging into the controller or access system as a power admin.

It could require additional steps based on which OSDP profiles and which devices are used, but whatever effort is needed is more than making Wiegand connections using D0/D1 ports. That's the rub.

Agree
Disagree
Informative
Unhelpful
Funny

Undisclosed #1

In reply to Undisclosed Integrator #3 | 07/09/19 08:12pm

OSDP is not more labor intensive if executed properly on most platforms.   Areas where I have seen misses include:  

- Procurement must purchase the right part numbers ready for OSDP out of the box or has ensured the right solution is ready (IE configuration cards) 
- The Technician is aware OSDP is being used, is aware of the wiring standard, and programming requirements
- The platform is capable...  (check that first.)
- The reader is up to date (OSDP V2 if you are using secure channel)

The result of a miss is that extra labor:   revisits to a site, waiting on materials, and egg on a face in front of a customer.   

Secure Channel does add some additional configuration as the communication is encrypted between the reader and the board.  Once paired, the reader and the reader port cannot be reused without first releasing their pairing.   You can imagine the headaches an untrained technician would have in this scenario, especially on a service call down the line.

Agree: 2
Disagree
Informative: 3
Unhelpful
Funny

Undisclosed #4

07/10/19 02:44pm

How about going with server based mobile credentials and just get rid of most of the readers, reducing cost and complexity. It's out there and it works.

Agree: 1
Disagree
Informative
Unhelpful
Funny

Nathan Adams

07/10/19 03:35pm

If you ask these same integrators how often they change default user names and passwords for their clients you will likely get the same percentage responses.  This is a matter of taking it upon yourself as a security professional to educate the customer.  If they then reject the technology because it would raise the total price of the project by 1% then that is their prerogative.  But most of these excuses sound like lazy integrators who wont adopt higher security standards until they are forced to. 

Agree: 2
Disagree
Informative
Unhelpful
Funny
Avatar

Salvatore D'Agostino

IDmachines | 07/10/19 07:08pm

Not sure if you know about this effort https://osdp.equipment/ 

Agree
Disagree
Informative
Unhelpful
Funny
Avatar

Brian Rhodes

IPVMU Certified | In reply to Salvatore D'Agostino | 07/10/19 07:14pm

Yes, we actually linked to it above too:

Not Supported By Access Systems

It also is clear that OSDP is simply not widely available as Wiegand in access equipment.

While the overall number of manufacturers supporting OSDP is growing, there are still significant gaps in support with several brands still limited to Wiegand:

Agree
Disagree
Informative
Unhelpful
Funny

John Honovich

IPVM | In reply to Salvatore D'Agostino | 07/10/19 07:16pm

That's great that Rodney et al are doing that, SIA or whoever controls OSDP should have an official listing that they validate.

Agree: 2
Disagree
Informative
Unhelpful
Funny
Avatar

Salvatore D'Agostino

IDmachines | In reply to John Honovich | 07/10/19 08:13pm

Yes John! Many are on board with this, and seriously thanks for beating the drum.

OSDP is going through steps. 

The acceptance as an international standard (IEC 60839 -11 ) annex (-5) is forthcoming, which is a process and very nearly complete. 

There have been a lot of implementations over time and its right to push for conformance.  We have seen quite a variety of responses to various commands across vendors but to be fair its not since the latest release that the work has matured to where it warrants being hard wired into mfgrs requirements.  Only recently can the vendor community fully implement the specification where it "can" be installed easily and securely,.  The OSDP Boot Camp, a joint effort of IDmachines, Smithee Solutions and SIA, along with a number of manufacturers, was a next step to provide hands on training and develop a curriculum for OSDP.  The first one had end-users, integrators and manufacturers and was very productive and these will be ongoing.  Part of the hands-on is device configuration and capability testing. 

The next step, as you rightly call out,  is an OSDP conformance and interoperability program.  The plan is to build on the ongoing engagement and take this into a testing and certification program.  This is underway.  I'd like to say it will be in place on the xth of SomeMonth but can't but I can say that the need is acknowledge and actions are taking place to meet the need.

Agree
Disagree
Informative: 1
Unhelpful
Funny
Avatar

Salvatore D'Agostino

IDmachines | 07/10/19 07:25pm

Thanks Brian, don't always click through, .  Sure there is more Wiegand than OSDP in the world and the deployment of OSDP is still uneven I think the point is that it is an option from a sufficient number of vendors and its security and communication capabilities make it more common with enterprise class customers.  The economics should be in its favor across use case, fewer wires, remote update, reader competition, nice to see some comments here back and forth.

 

Agree
Disagree
Informative
Unhelpful
Funny
Avatar

James Talmage

IPVMU Certified | 07/11/19 04:08am

We're doing our first OSDP deploy next week (six of em).

For us, the motivation is cost savings on doors with entry and exit readers. OSDP allows you to daisy chain multiple readers on a single mercury card reader port. $60 more per reader * 2 readers, is well less than buying a second MR-50 (same for 4 readers and an MR-52).

And, it all really seems like an intentional software limitation. OSDP would allow for far more than two readers per port, and with the number of available inputs and relays on an MR-52 there's no good reason it couldn't handle 4+ doors (with entry and exit readers on each).

Agree
Disagree
Informative: 1
Unhelpful
Funny
Avatar

Scott Fischer

Lorica Consulting LLC
IPVMU Certified | In reply to James Talmage | 07/11/19 12:30pm

When I brought up daisy chaining multiple readers using OSDP to our integrators, I was told there is no point to daisy chain readers because you still need to run cable from the enclosure to each door to operate the other hardware (locks, DPS, etc.).  Can you share how you address that issue?

Agree: 2
Disagree
Informative
Unhelpful
Funny
Avatar

Brian Rhodes

IPVMU Certified | In reply to James Talmage | 07/16/19 02:03am

We contacted Mercury directly on this application - using OSDP to potentially provide savings on buying additional hardware. Mercury's response:

To directly address the statement in question, the Mercury MR52 was originally designed to support 2 readers.  We updated the firmware, at no extra cost, to give the ability to handle up to 4 OSDP readers in the in/out configuration or primary/alternate configuration.  We do have a few extra inputs/outputs on the board but these were not intended for additional doors and are more for auxiliary functions.  Most of our partners have these points hardcoded in their software, so a change to this, as always, has many downstream consequences in our ecosystem that we need to be cognizant.

On the issue of potential cost savings, Mercury suggests the additional labor may cancel out hardware costs:

At some point, the labor cost to configure all this, wire the readers, troubleshoot, etc., makes the cost of perhaps adding another downstream board irrelevant.  In addition, for resilience and business continuity, how many readers do you really want to connect to one port on one board?  Our intelligent controllers, for example, can support 128 readers, but I don’t know anyone that maxes them out.  Same situation here with OSDP readers.  At some point, does it make sense to put too many reader on one line / port.

And on the issue of 'daisy chaining' readers together:

The real challenge with multi-dropping OSDP readers is addressing the readers to be used on the same bus.  In our experience, this can cause unnecessary complications during the install.  Today, since most readers don’t have dipswitches or any external means to configure, the integrator needs to use reader configuration cards or a programmer like HID Reader Manager, etc., to set up the address on each reader.  This could add time / complexity to the install.  Alternatively, we can configure the reader through the Mercury hardware using our auto discover feature and then program the address / baud rate.  But this only works if there is 1 reader connected per port.  If there is more than one reader on the port, we have no way of knowing which is which so this functionality is disabled.

Overall the response is insightful and raises the issue in if the extra configuration labor cost makes multi-drop deployments less expensive.

Agree
Disagree
Informative: 3
Unhelpful
Funny
Avatar

ROBERT VERHULST

07/18/19 07:22am

As a consultant, I refuse all Wiegand interfaces. Even when cabling is well protected it does not give any information on the state of operation of the reader and has to be avoided.

Agree
Disagree
Informative
Unhelpful
Funny
Read this IPVM report for free.

This article is part of IPVM's 7,201 reports and 959 tests and is only available to subscribers. To get a one-time preview of our work, enter your work email to access the full article.

Already a subscriber? Login here | Join now
Loading Related Reports