Mercury Open Access Hardware ExaminedBy: Brian Rhodes, Published on Jul 15, 2013
Everyone wants an "open" access platform, yet no one delivers... or do they? One of the biggest names in access control is one most end-users rarely hear mentioned but widely used. Mercury Security's entire portfolio is composed of open hardware, and in theory, can be reused when changing between platforms. In this note, we look at Mercury's openness and interoperability in the access market, and identify where the issue gets cloudy: Just how far does "openness" go?
A sizeable swath of EAC vendors purchase hardware from, or design systems to work with, Mercury hardware. The company does not sell it's own brand to end users, rather instead focusing on OEMing equipment for vendors who use Mercury's API to customize software interfaces to the equipment. The standard hardware offering to OEMs includes a handful of products, notably the EP2500 and EP150x controllers, and the MR5e single door interface panel:
Other Mercury SKUs exist, including other interface panels and the M5 Casi-Rusco "Bridge" controller board, but regardless of their rebranding, all hardware is the same, including the same firmware. This is the cornerstone of Mercury's "Open Hardware" identity - regardless of vendor, the hardware behaves the same way and interfaces with software using the same framework.
Powered vs. Authentic
While Mercury's marketing and branding is not targeted at end users, the way the company applies branding labels denotes significant differences. For example, both "Mercury Powered" and "Mercury Authentic" are referenced by the company's partners, but they denote distinct OEM relationships:
- "Authentic Mercury": This tag denotes a partner company uses both Mercury Hardware and firmware in its access platform.
- "Mercury Powered": However, this tag indicates that only Mercury firmware is being used with hardware designed and manufactured by others. Notable examples of this include Keri Systems, and the Ingersoll-Rand PIM400-1501 used with AD series door locks. The advantage of using Mercury's embedded firmware to power hardware is that the hardware is instantly interoperable with a vast number of access control systems.
While 'Authentic Mercury' hardware is interchangeable and available for a number of resellers, 'Mercury Powered' hardware is typically fixed to a specific part number from a specific provider. Take for example the IR PIM400-1502; While the firmware is interoperable, the hardware is exclusive to Schlage AD series wireless locks.
Interestingly, while discussions of access interoperability standards are heating up, Mercury has become a 'defacto' interoperability standard through growth of it's own market share. However, unlike a true 'interoperability' standard, "Mercury Powered" is licensed by the company and not composed of a consortium of many vendors.
Even when systems use the same Mercury controllers, this does not guarantee that every vendor writes software to support the same operations. Features like 'anti-passback' controls or alarm monitoring notification are solely dependent on the software vendor to implement, and even if the hardware is interchangeable, the platform differs.
Features supported by Mercury hardware, but not always supported by access vendors include:
- Multiple Occupancy, or "Buddy System" Rule
- Multiple System Trigger "Hold Open' Alarms
- Elevator Controls
- Individual Asset/Group Asset Tracking
- Area Counting
- First Card Unlock Override
Not every EAC vendor using Mercury hardware supports every hardware part number. While the hardware may technically work, if the EAC vendor does not support the specific controller or interface model, it can put the end user at risk when seeking technical support.
Aside from the list of Mercury's largest OEM Partners (see: Mercury's "Platnium Partner" Roster), there are numerous other players that also are interoperable or use the company's hardware. A recent discussion topic listed several of these names, including S2, Stanley/Best, Tridium Framework (Honeywell), and Imron.