S2 Limitations

What are the most common and distinct limitations with S2 in terms of functionality for large multi-campus environments of 5-600 reader capacity?

Cheers!


Hello Undisclosed:

An executive at S2 sent this response to your question. In addition to your question, I asked specifically:

  • "Does an S2 system scale price wise the same as 'traditional' hardwired panel system?"
  • "[Are there any] functional challenges being web/browser based vs. standalone comm server?"
  • "How does integrating a VMS differ?"

The response follows:

"Because of the diversity of the applications we get, we offer several product ranges, and the architecture of the system is different for each. A 600 reader system requires one of two solutions from us: 1) a single S2 Enterprise system; or, 2) multiple small S2 systems and an S2 Global system to manage them.

Which solution you choose depends on the application specifics. It would be reasonable to use a single server running Enterprise if the campus was fairly geographically contained and the communications infrastructure was solid. On the other hand, if the campus is distributed, then there may be both functional and design benefits from using a "network of small systems" approach.

The monolithic system approach is the approach offered by every credible manufacturer, and ours is priced competitively with UTC, Tyco, etc. One place our pricing policies differ from others, though, is that we don't charge by the user, and a lot of end users like that.

S2 also offers the distributed system architecture, which offers real benefits for geographically distributed users. Our approach to distributed systems is quite different from the rest of the industry. You can build an "S2 ecosystem" out of our SMS and VMS appliances, and have them managed from one of our global management systems.

Long answer, but there you have the details. As for what challenges are imposed by delivering the user interface through a web browser, pretty much the challenges are on the designer's side and the benefits are on the user side. It takes much more effort (several times the effort) to design UI that runs in a browser than as a thick client. And we have to qualify the product with every browser individually. So it just costs more to engineer that way.

On the other hand, who isn't thankful when a software change doesn't have to be installed on every client computer?"

On advanced system integrations, like VMS platforms:
"VMS integration in a browser can be successful, but the available technology imposes limitations. Most manufacturers provide an ActiveX control that can be embedded in a web page, and most of our third party VMS integrations do that. The idea with ActiveX is that you can have native code running under control of the browser.
S2 achieves this in a different way that avoids some of the visual pitfalls of ActiveX, but the idea is still to have the heavy math done in native code. From the user perspective, though, the fact of using a web browser seems like running a thick app."

If you have specific questions to ask or followup I will pass them on.

We normally run Extreme or Enterprise Controllers with each geographic site partitioned via Nodes and connected back to the controller. Global is a very expensive option, but would be preferred if price was not an option. Very good product with good integration with many VMS solutions. Their new "forensic desktop" enviroment pairs their Linux controller with Exacq Linux Server. The greatest thing about this "appliance" based product (no SQL server) is that it never fails. (A recent IT administrator, who was gung ho with VM, was biased that this could not be virtualized. I responded "do you virtualize your firewall, switches, and life safety panels?").

Can you elaborate on the integration for Enterprise to a VMS system like Eqacq? Are there limitations worth discussion?