printer friendly version

A truly open architecture - the standard for access control

The last decade has seen a move away from the independent or standalone systems, where even programs running within a single computer had no ability to interface with one another, or share data. Databases comprised various flat-file structures that were dreamed up by the aspirant programmer, and were impossible for third parties to add to or change, as the code was specifically written to accommodate the structure.

These independent islands were a nightmare for the IT managers, as they had to fight department heads who all wanted to paddle their own canoe and would not share the information that was generated by their department.

The phenomenal change in today's computing is the demand for a total open architecture where no importance is placed on the platform that is chosen, the language in which the program is written, the structure of the data or the location of the hardware holding the information. Movement to Java, .NET, XML and the Internet underlines the move to a completely open architecture where the user insists on being able to extract information from any source, at any place, and without ever having to capture the information twice.

This drive has placed enormous strain on the hierarchical structures of the access control industry of yesteryear, as the source information used by this industry forms the basis of all HR systems. The corporate customer is now calling for all vendors of access systems to supply the transaction information captured by the access control system to time and attendance, payroll, job costing, canteen management and similar applications. The costly, time consuming, error prone action of information capturing the HR applications need to form the basis of the configuration data used by the access control system, without the need to retype in the information using the vendor's application. Also, HR want to make the decisions on where the staff can go (and when).

Further, each customer requires applications around their specific needs to be accommodated by the supplier of the access control system. Unless the design of the product encompasses the ability to address these requirements independently of the vendor, the task is virtually impossible to accomplish, without spending valuable software resources in pursuit of a custom solution, which is very difficult for the vendor to support - invariably, service levels sink to the floor.

The above requirement became apparent to access control specialist Impro a few years ago and a major new product development was undertaken to address these issues. ImproNet concept as used in the IXP400 range. The drive was to develop a truly open system with the following features:

* Open SQL client/server database.

* The transactions that are in the database are available to third parties.

* Customer information from other programs eg, SAP, can be used to supply information to the access control database. This set-up data would need to automatically find its way into the controllers, in spite of the hardware being fully distributed.

* A customer written module can control the access validation process in the (distributed) hardware in realtime.

* Fully integrated 3rd party programs eg, CCTV, time and attendance, job costing, asset tracking, canteen management and the like can be effected without reference to Impro (using the standard interfaces provided).

Interactive hardware eg, the measurement of a particular parameter like mass, can be integrated into the hardware by user customisation, interact with the decision making process, and alter the normal course of decision making.

* Independent of platform, ie, Microsoft, Linux, Unix operating systems could be considered.

The hardware was made to implement a simple but efficient high-speed ASCII communications protocol, which allows anyone to interact with the units in the field in realtime, with authentication to protect against unauthorised use. This protocol 9 the ImproXProtocol) is publicly available on the Internet.

The choice of the software development language was fundamental to the ability of meeting most of these requirements. Java was selected some four years ago, while still in a relatively infant state where it was extremely difficult to obtain assistance from the tools vendor, and many compiler bugs existed. In fact 100% pure Java was decided on to ensure platform independence in the future, and this goal has been achieved.

Standard network socket support for communication allows the user to interface directly with the hardware in the field by transferring instructions to the ImproNet engine, using ImproX Protocol frames. Sockets can also be used to provide a customer module with a realtime view of the access transactions as they are occurring.

Third party validation will instruct the controllers in the field to pass information from tag holders who are requesting entry directly to a customer module for a decision to be made, eg, people entering a specific zone might require that SAP decides on the validity of the request, and will respond with access allowed or denied.

The product also offers web-based reporting, that keeping true to the philosophy of 'information at your fingertips'

Share this article:

Further reading: