List Of Open Access Control Manufacturers

I am looking for a list of manufacturer's that are Open Architecture - from what I understand this generally mean's Mercury or HID controller OEM's. I understand that generally these platforms will lessen vendor lock-in and offer easier integration. I am writing from a specifier's perspective. I am working for client that currently does not have a standard product so we are free to explore all options. I am looking at traditional options at this time, it seems like mercury panels appear the be the more popular traditional controllers but HID is the more popular edge controller.

Some research has led me to this so far - not all manufacturer's explicitly state so I may be wrong on some:

Mercury Based (website mentions 17 partners, but does not name all):

  • Lenel
  • R2S
  • Open Options
  • Honeywell (?)
  • Red Cloud
  • S2
  • Brivo
  • Maxxess (appear to have mercury and HID options?)
  • Keri Systems (I can find news/press releases - but not product listing on webpage)
  • Genetec
  • Stanley/Best
  • Identicard
  • Imron (?)

HID Based:

  • Automated Management Technologies
  • Averics
  • CBORD Group
  • Genetec
  • IDN-Acme
  • Imron (?)
  • Maxxess (?)
  • Next Level Security Systems
  • RedCloud

Proprietary:

  • Kantech
  • GE
  • Software House
  • Johnson Controls
  • AMAG
  • Keyscan
  • Gallagher
  • DSX

If people could help modify/expand this list it would be great! Brian, from what I observe you may be the best at initially "fixing" this list, then we can run with it?

Thanks all

John


John, thanks for putting together that initial list! Let's see how much we can expand on it!

I added Software House to the proprietary list.

Stanley/PAC - Proprietary

I can confirm Imron uses both HID / Mercury

Here's a few more 'Proprietary" Lines:

  • S2 (IEI/Linear)
  • Paxton
  • Identive (Hirsh)
  • Continental
  • RBH Access
  • Infinias

ICT (Integrated Control Technology) - Proprietary

Are Mercury Controllers directly interchangable between access control manufacturers? For example, if I have a Lenel system and want to replace it with an Open Options systems, can I just connect the existing controllers to the new server, or must other modifications be made?

It is my understanding that some Mercury controllers use proprietary firmware and that this may need to be changed in order to make a new system work.

Also regarding Mercury being interchangeable; we have found that as long as a reader board was designed around a Mecury chip, even if it was one with a moderately brand specific one (Honeywell); as long as it is a socket-based chip and on a SMT soldered-to-board chip, you should be able to replace the chip with a generic MR50/52 etc chip from Mecury and use it as a generic Mecury board. YMMV...

Holy cow, that is equal parts impressive and terrifying at the same time. Quite the gamble, if you're guessing it will work!

I don't think all Mercury boards need a flash, from what I recall. Some of them just use the standard chips. I can't tell you exactly which ones, though! I know that Honeywell definitely used to require a chip change, but I heard that may not be the case anymore.

@Ethan, as you are basically saying, the problem is that we have seen 6000/6k series Prowatch boards that the chips are swapable, and 6000/6k series boards that aren't haha. We've heard/seen that a lot of the older boards were socket based and swapable/compatible, whereas the majority of the new ones are soldered in, and non-replaceable or re-flashable. Again our experience has been very limited with it with the Genetec SMC, but we have gotten lucky so far.

[IPVM Editor Note: Poster is from Mercury Security.]

It is important to specify, when talking about "boards", whether you are talking about Controllers or Interface Modules. Examples of Controllers would be the "EP", "SCP", PW3K, PW6K, LNL-2220, LNL-3300, and so on. Examples of Interface Modules would be the MR52, PW6K1R2, LNL-1320, etc.

Controller firmware has been flashable since at least the late 90's. Older Interface Modules were socket-based, newer ones surface mount and flashable.

Quintron integrates with Mercury, HID (VertX & Edge), BridgePoint, DMP, Schlage AD series, Tridium & maybe Salto. Plus, they can hang them all, intermixed, in the same system.

Are you also considering the server and (thick) client OS openness? Will you be investigating the ease of the UI customization, in order to reduce training and the need for familiarization with the system to perform basic and\or infrequent functions, especially under duress? Will you be factoring in the ease & inclusion of custom function (and report) creation, as key useability requests\requirements are not always uncovered until the system has been under operation for a while? It's better if a customer could benefit from (some) customization without incurring a charge. These are Quintron strong points, too and factors of my favor for and specifying of them.

Keri Systems offers both a Mercury-Powered firmware version of their NXT controllers, as well as real Mercury panels. Information can be found here.

Bosch ReadyKey Pro uses Mercury, but it is pretty much rebranded Lenel.

Here is HID's list of IP access control partners.

MDI (Monitor Dynamics, Inc.)?

[IPVM Editor's Note: MDI went bankrupt but reportedly is coming back now.]

Thanks for the reply guys.

List updated with posters' comments:

Mercury Based (website mentions 17 partners, but does not name all):

  • Lenel
  • R2S
  • Open Options
  • Honeywell Prowatch
  • Red Cloud
  • Brivo
  • Maxxess (appear to have mercury and HID options?)
  • Keri NXT
  • Genetec
  • Stanley/Best
  • Identicard
  • Imron (?)
  • Bosch ReadyKey

HID Based:

  • Automated Management Technologies (AMT)
  • Averics
  • CBORD Group
  • Genetec
  • IDN-Acme
  • Imron (?)
  • Maxxess (?)
  • Next Level Security Systems
  • RedCloud
  • Wren Solutions
  • Johnson Controls - EDGE ONLY

Proprietary:

Thanks undisclosed, I will review Quintron's offerings.

Brian, you noted controller openness maybe shouldn't be a high priority item to Owner's. Is this because there are just too many complexities to really count on being able to reuse controllers in the future should an owner want a software platform change (which is rare according to previous articles)?

How about from an integration point of view? In general, does the "mercury platform" make integration any easier on the VMS vendor's? i.e. once a VMS vendor creates a direct integration with one mercury panel, can they can more easily "port" code over to other mercury "flavours"? Or is one mercury flavour to the next just a difficult as going from on proprietary controller to the next?

Thanks

I think you should keep S2 on the "open" list. While they do offer both their own panels and Mercury, you can configure a system with JUST Mercury hardware

Monitor Dynamics\MDI uses only proprietary hardware.

Also, the software is the integration engine that ties access and video solutions together. So, if you have a Mercury-Milestone integration with an existing access software vendor and you replace that software with a new vendor, the new vendor would need to have or develop their own Mercury-Milestone integration. A very interesting prospect for Mercury, but a nightmare to keep up to date, with all the changing video players and versions.

In takeovers, as we are eluding to, you would also look to be able to import as many data tables as possible from the existing system to the new, including cardholder and panel input information (including transposing reader\access rights), in order to reduce data entry for the new system.

Brian, you noted controller openness maybe shouldn't be a high priority item to Owner's. Is this because there are just too many complexities to really count on being able to reuse controllers in the future should an owner want a software platform change (which is rare according to previous articles)?

"Open hardware" like Mercury or HID allow the potential to change platforms (depending on the mix of hardware installed), but no one should expect just because the brand says 'Mercury" or "HID" that it will be cheaper or even possible to repurpose hardware during a changeover. Not all EAC platforms support all models of "open" controller hardware.

How about from an integration point of view? In general, does the "mercury platform" make integration any easier on the VMS vendor's? i.e. once a VMS vendor creates a direct integration with one mercury panel, can they can more easily "port" code over to other mercury "flavours"? Or is one mercury flavour to the next just a difficult as going from on proprietary controller to the next?

Undiscloseds thoughts on this, specifically the example "If you have a Mercury-Milestone integration with an existing access software vendor and you replace that software with a new vendor, the new vendor would need to have or develop their own Mercury-Milestone integration." accurately portray the prospect. Integration is not typically done at controller level, but at 'head-end' level. The controller can send outputs used by the integration, but the interface is typically done upstream.

Brian. From a consultant's point of view, Mercury (and HID) are my go-tos, but for a different reason. When a Client wants to change out his system, its often linked to the integrator loosing his distributorship or simply going out of business and no one is around to service the product (i.e. GE). The Mercury panels are the most prolific and have the most partners ("the HID" of the controller world"). That being said, as of last March, they do not have a peer-to-peer controller. Genetic, S2 and probably others provide their own, which is a good thing if you need controllers to talk to one another without the server present.

One final point, Johnson Controls has supported Mercury for about a year now. Schneider Electric will also be phasing out Continuum and moving entirely to Mercury (on the security side) in 3-5 years (not sure if they can sell it now).

Additions/modifications to the list:

Access Specialties Inc (ASI) - Proprietary and HID Edge/Vertx controllers

AMAG - proprietary controllers.

Maxxess - Mercury and HID Edge/Vertx controllers.

BadgePass - some Mercury controllers (I don't think they suppor the Mercury MR50).

Linear - Prorietary

I acquired a list of Mercury partners that may or may not be accurate. Perhaps someone can confirm these??

It also includes:

Quintron Systems Inc

Arinc Corp.

Honewell

Imron

Next Level Systems

GS4 - Touchcom

Midpoint Systems

RF Logics Inc

Digiwatch Systems

Mercury's website lists a group of "Platinum Partners", but I it does not appear to be an all inclusive list of every access control system manufacturer that is based upon or uses Mercury hardware, for example Genetec.

RF Logics does not work with Mercury controllers. They only use proprietary panels.

So in summary it seems that i can make the following conclusions in terms of specifying an "open platform" access control system.

1. Vendor Lock-in: Choosing a Mercury or HID hardware based system marginally increases chances that you have an "out" from vendor lock-in in the future. However, conversely - choosing a proprietary system makes vendor lock-in certain.

2. Integration: Choosing "open platform" access control software may increase integration options as it allows VMS (and other systems) to create integrations should they see a benefit in doing so.

It feels like I am oversimplifying a very complex topic, but am I somewhat on the right track ?

Hi all, I realize that this post lost momentum but so that I can potentially close the loop and give the research (and brain) a break for the weekend, any thoughts?

Thanks!

Sure. I think the important thing to realize is, open or not, your access control hardware is a but a part of a larger full system. You will certainly get a level of vendor mobility by choosing Mercury or HID hardware over proprietary hardware. That said, the entire system has to be considered as a whole, as the host software might talk to obscure video, badge printers, intercoms, HR, climate control systems, etc. These have nothing to do with Mercury or HID, but may reduce your customer's feasible alternatives later.

Essentially, it may be a good idea to do a "gap-analysis" before the fact, and make sure the components of the rest of the system are as open as the access control hardware.

I am preparing a post on this topic, based on continued research. There are a number of points that need to be clarified (for example, I've learned that while HID controllers need a firmware reflash to change systems, Mercury Hardware does not.)

It bears emphasis that not every EAC vendor using 'open hardware' supports every part number made by these companies. While the hardware may technically work just fine, if the EAC vendor does not support that specific hardware, it can put the end user at risk.

Mirroring 'Undisclosed' comment above, while it may be helpful to hang 'open' hardware, access changeovers are not a 'casual' thing. The 'openness' of the hardware is one aspect of a larger system picture. System usability, valid database contents, and integration with other systems (can) dramatically change between "open" hardware-based systems. As stated above, integration and usability is primarily associated with 'head end' software design.

This is an interesting topic, and I am pulling together salient points for general reference. Great example of a Discussion topic delivering real value. 'Thank yous' to all who have participated!

Brian. Can i assume you will post your sailient topics for us to view?

Whether by need or as a ploy to make takeovers more difficult, manufacturers are and do have the ability to make more secure their future with current customers. For example, Lenel has been deploying their new NGP panels to, it seems, as many of their large installations as possible. These are Mercury Gen 1 code based, but are purely and, reportedly, forever proprietary. Sometimes it is a good idea to have the flexibility to add an HID POE reader to key places in an otherwise Mercury baseline system, or to similarly add wireless lock sets to otherwise difficult or costly to reach areas.

What I feel is that, in the end, standards will be best for the customers, but in the meantime, while looking out for the customer’s future is appropriate, panel purity does not need to be absolute. Takeovers of Mercury and HID panels will usually involve a cost to flash each panel’s OEM specific firmware with the new vendor’s OEM specific firmware, so it will usually not be a cost free swap, even to keep the same panels. So, I like it as a rule, but not an absolute. As discussed earlier, there may be other third party integrations that do not natively transfer (video, visitor management, perimeter, IDS, HR databases, custom reports, custom features,…).

You may also consider, depending on the facility types you have, integrating the burglar alarm & fire (secondary reporting, of course), such as Lenel is doing with their proprietary NGP (burg only) panels, Honeywell does with their Vista panels and others are doing with DMP (much more flexibly than even the native Honeywell integration, I have experienced). Or, if an outside central station is not needed, you can use the Mercury keypads for off-hours burg type security, reporting back to the user-monitored server. In either case, it affords you much more flexibility and control over your security processes.

OK. Two more pet features that could save your customer some grief.

So, if you are securing a multi-facility complex or multi-location monitored organization, you might need to be sure the system has alarm vectoring, so only the regionally pertinent and tailored info is sent to local workstations, preventing inundation are the head end with every minor goings on. Further you may need an automatic escalation of that event to the head-end, or alternate location, should the primary responding location fail to do so in time. Finally, partitioning the database goes hand-in-hand with multi-tenant and multi-site facilities, for both operator convenience and privacy concerns.

Thanks all, I appreciate the effort and the great responses to my request!

Averics Cogito

Sielox

Proprietary panel. The website claims it is the most advanced access control panel in the industry yet it didn't even make the list made by industry professionals? Amazing claim. I would never install it with all of the options available but I have a customer I have been trying to move to a Mercury based solution swear by the product like it was the best thing since sliced bread.