|
1. What is the difference between Mercury’s EP and AP products?
2. What support will Mercury provide our company if we decide to use your hardware and firmware?
3. When would Mercury’s Embedded Technology best be applied?
4. Can Mercury support our systems and product development overseas? What are the limitations?
5. If we use Mercury controllers such as the EP 1502 or the EP 2500, must we also use related Mercury products such as the MR series?
6. Can Mercury products meet our changing network and product upgrade demands? How?
7. As a security system OEM, we must be accountable to end-users and system resellers, distributors or installers. How will Mercury contribute to that accountability?
9. How do I configure the card formatter to decode my card?
10. What is the difference between triggers and procedures?
11. How do I make certain that my access network communications is secure?
1. What is the difference between Mercury’s EP and AP products?
Since its inception, Mercury Security has pioneered innovative, reliable hardware to meet the changing needs of our OEM customers. That innovation began with the SCP line of controllers, which evolved into two distinct product lines: the AP and the EP.
Providing the same exacting levels of reliability, the AP and EP differ mainly in terms of their on-board network features and overall system capacity. AP controller platforms are a value-driven option offering OEMs a flexible non-native, building-block approach to system design and configuration capable of a maximum 64 doors and built for access control. They are ideal when OEMs require an introductory level system that does not require native network features.
The EP access platforms provide enterprise level capabilities with advanced, on-board “native” network features. Powerful, scaleable, the EP platforms also provide a flexible, building block approach to system design and configuration.
2. What support will Mercury provide our company if we decide to use your hardware and firmware?
Mercury provides a range of OEM partner-customer support.
From documentation to one-on-one field consultations, our development support team provides the technical guidance customers need to ensure precise and high-performing systems, shortening the time to market.
In addition, Mercury’s quality assurance and customer support teams are equally responsible for performance and support of all products throughout the customer’s procurement and implementation process.
Mercury also provides a growing range of digital resources. Consider visiting our “How To” and our on- line “How Do” Web page to “Ask the Experts.” [link to How To/application landing] We will also be launching a Partner Portal resource on our Web site.
3. When would Mercury’s Embedded Technology best be applied?
Mercury’s Embedded Technology is best applied when an OEM wants to add access control capabilities to its video security or building control offering, and the OEM has an available piece of hardware with an appropriate CPU capable of hosting the embedded application. Because our Embedded Technology requires only 1MG of memory, adding our proven and advanced access control capabilities via an embedded solution can be efficiently and easily accomplished.
4. Can Mercury support our systems and product development overseas? What are the limitations?
Yes. Mercury readily supports product development and systems overseas. Typically in global relationships, we work through our customer’s headquarters as an integrated adjunct to their engineering and technical support teams. We provide all system documentation in English, so translation typically resides with our OEM partners. Located in California and operating on Pacific Time, we coordinate with our partners to overcome any time zone and working hour variances.
5. If we use Mercury controllers such as the EP 1502 or the EP 2500, must we also use related Mercury products such as the MR series?
Yes. Mercury’s EP product line is engineered to provide a modular “building block” for system design and configuration. As systems are designed and planned, Mercury’s EP controllers can be readily interfaced with Mercury’s MR series as required.
For example, for two reader control and ancillary point monitoring, a system based on an initial use of an EP2500 needs the MR52 for expansion.
6. Can Mercury products meet our changing network and product upgrade demands? How?
The short answer: Yes. The EP line of controller platforms is continually refined as our OEMs customer’s security environments evolve. This provides our customers a proven platform to efficiently upgrade the features needed for their installations and increase the value of their solutions.
7. As a security system OEM, we must be accountable to end-users and system resellers, distributors or installers. How will Mercury contribute to that accountability?
As strategic partners providing engineering and hardware to our OEM customers, Mercury stands shoulder-to-shoulder with our partners to provide any needed problem-solving -- wherever and whenever necessary. Our commitment to engineer and provide reliable, tested and field proven products answers end-users and resellers needs
8. Does Mercury sell the same firmware and hardware to my competitors? If so, how can we trust the exclusivity and integrity of our system solution when our competitors are also using the same core products?
While Mercury provides common platforms, those platforms are based on our distinct feature sets. How these platforms are enabled by our OEM’s are subject to their implementations and vision.
9. How do I configure the card formatter to decode my card?
Our card formatter logic can interpret binary and decimal data streams, process various check codes and is able to extract user ID from specified fields.
Mercury recognizes the complexity of this process and provides support and training to assist in the creation of format specifications to match cards.
The Mercury EP platform is capable of supporting up 8 individual card formats per intelligent controller. Once created, a library of common formats can be built.
10. What is the difference between triggers and procedures?
A transaction is an event detected by the EP controller and logged for reporting to the host.
The Mercury definition of a trigger is the occurrence of a specified transaction in the system. Triggers execute to invoke procedures.
The definition of procedures is a sequence of one or more actions performed when the procedure is called upon to execute. Each action represents a control command such as relay control or door unlock.
11. How do I make certain that my access network communications is secure?
Data transfer is considered secure if either the transfer method is secure such as documents carried in a diplomatic pouch or if the data is unintelligible during the transfer, more commonly known as data encryption.
One must accept that any data that travels over a public network is not secure. In fact, even data on private corporate networks shielded from the outside by firewalls is generally accessible at many of the network drops within the facility.
>Since corporate networks do not provide a “secure transfer” mechanism, encryption must be used to secure the data. Realizing the potential exposure, Mercury Security’s network connected Intelligent Controllers began offering NIST Certified FIPS 197 encryption in 2003. The U.S. Government has approved this level of encryption for securing classified SECRET documents.
All IP-capable devices introduced by Mercury since that time, including the newest MR51e door controller, implement the same FIPS 197 compliant data protection. In addition to securing data on the Local Area Network, Mercury offers the same level of encryption between the Intelligent Controller and the door control and monitoring hardware on the RS-485 network. Should the site security requirements warrant, the data can be encrypted all the way from the host application to the unit that reads the cards and unlocks the door.
|
