Knowledge Base Article
Crystal Matrix
Interface Comparison
TCP/IP vs. SDK
Copyright © 2008-2012, ISONAS Security Systems
All rights reserved
Table of Contents
1: INTRODUCTION ... 3
1.1: TCP/IP INTERFACE OVERVIEW: ... 4
1.2: SDK-BASED INTERFACE OVERVIEW: ... 4
2: DIFFERENCE BETWEEN SDK AND TCP/IP OPTIONS ... 5
2.1: MAKING THE DECISION ON WHICH OPTION TO USE. ... 5
2.2: INITIAL IMPLEMENTATION. ... 5
2.2: SIX MONTHS LATER (VERSION 2). ... 6
2.3: SUMMARY. ... 7
Document Version
( KBA0040InterfaceComparison.Doc )
Date of Revision Revision Author Description 1/3/2008 1.0 Shirl Jones Initial Release
SDK vs TCP/IP Comparison 3
1: INTRODUCTION
The ISONAS Crystal Matrix Software supports a number of methods to interface the access system with exterior systems. The vast majority of interface projects use one of two interface options. This document outlines these two choices, and through an example describes where each option is appropriate.
In this document, we will reference to the two systems involved as: “ISONAS System” & “Associated System”
The two interface methods that we will focus on are the TCP/IP interface, and the Software Development Kit (SDK).
Below are two diagrams, showing a typical network topology used with the two options.
When the TCP/IP interface is used, the ISONAS System host manages the site’s installed reader-controllers. The Associated System transmits commands and data to/from the ISONAS System host.
If the TCP/IP interface was connecting a Human Resources system to the ISONAS System, then this data from the HR system may be a new personnel record for the ISONAS System to add to the ISONAS databases
If the TCP/IP interface was connecting a Video Management System to the ISONAS System, then this data may be event data coming from the ISONAS System that the Video Management System uses to bookmark related video clips.
When the SDK is used, the Associated System makes all the decisions, and handles all the low-level communications with the network of reader-controllers. The ISONAS host is not involved. The Associated System will need to have “personnel” databases, “scheduling” databases, and a database of the reader-controllers. A Building Control System might use the SDK to control the reader-controllers directly from the Building Control software.
1.1: TCP/IP INTERFACE OVERVIEW:
1. When using the TCP/IP interface, the ISONAS Server provides the “access control” logic. It’s programs and databases handle the details of who is admitted, when they are admitted, and where they are admitted. 2. The ISONAS Server provides the communications functionality. The
Associated System does not have to worry about handling the IP traffic to/from the reader-controllers. The ISONAS Server provides heartbeats, IP message retries, and manages the IP socket connections.
3. The message structure used between the Associated System and the ISONAS System consists of easy to read, text-based messages.
a. For Example, if the Associated System is requesting that the “Front Door” to be opened, the syntax of the request would read:
<ADMIT><FrontDoor>|
4. This is an easy solution for the Associated System to implement. This interface has a simple message format. The Associated System only needs to implement the features that it requires control over, not all the
functionality that the reader-controllers require.
1.2: SDK-BASED INTERFACE OVERVIEW:
1. The ISONAS reader-controllers are used, but the Associated System supplies all the server-based software functionality. The Associated System
understands the basic access control concepts related to who/where/when access is granted.
2. The Associated System communicates with the ISONAS reader-controllers using the messaging structure defined within the SDK. These messages are designed to conserve network bandwidth, so they are short, binary
messages.
3. For most applications, the reader-controller’s standalone mode is an important reliability feature. In these cases, the Associated System maintains and updates the reader-controller’s on-board standalone databases.
SDK vs TCP/IP Comparison 5
customer training, since they only need to be trained on one system.
2: DIFFERENCE BETWEEN SDK AND TCP/IP OPTIONS
2.1: MAKING THE DECISION ON WHICH OPTION TO USE.
How do you make the decision on which interface to use, the TCP/IP interface or the SDK?
To help illustrate the advantages of the two options, we will follow a fictional example company thru their implementation process.
“Clock-In, Inc” is a time and attendance software company. They are looking to expand the flexibility and cost-effectiveness of their product line, by adding support for the ISONAS IP reader-controllers.
They have reviewed these two interface options, and because of required delivery schedule, and limited availability of development resources, have decide to
implement this integration through the use of the TCP/IP interface.
2.2: INITIAL IMPLEMENTATION.
The functionality Clock-In is implementing includes:
The Clock-In software maintains the master personnel database, and the TCP/IP interface is used to update the ISONAS personnel database from the Clock-In system. TCP/IP commands are used to add/change/delete specific personnel entries in the ISONAS database.
A personnel data purge-and-resync process will be implemented to purge the ISONAS personnel file, and then re-populate it with data from the Clock-In database. This functionality is used during initial system implementation and as a fall-back method to re-sync the two system’s databases.
The ISONAS System will notify the Clock-In software whenever people
present their badges to the ISONAS reader-controllers. The Clock-In software will use that information to update its attendance database.
This project’s implementation is straightforward. The Clock-In software’s interface establishes an IP socket connection to the ISONAS system, and text-based
commands are used between the two systems. Clock-In is able to quickly announce that their system is now available with a 100% IP and PoE solution set.
2.2: SIX MONTHS LATER (VERSION 2).
Clock-In has installed their IP-based solution at a number of their customer sites. The market acceptance has been great. But like always, the customers are asking for more.
To address these needs, Clock-In designs a simple companion module to the ISONAS reader that gives the user feedback to their status when they “punch-in”. If the user is on-time, then one sound is produced by the companion device. If the user is either too early or too late, then the companion device produces another sound.
The reader-controller is able to provide plenty of power for this companion device. The reader-controller’s input & output lines can be used to control the companion device, but it is determined that the logic required to control the device is not convenient to implement when using the ISONAS software.
In addition, after installing a number of sites, it is recognized that by eliminating the ISONAS software at the customer’s location, there will be one less area requiring training for the installers and end-users.
So, Clock-In develops “Version 2” of their interface, which will directly control the reader-controller from within the Clock-In software. With this implementation, Clock-In has full control of the actions of the reader-controller.
This integration will be done using the messaging structure that is described in the ISONAS SDK.
SDK vs TCP/IP Comparison 7
The Clock-In software will be responsible for a number of house-keeping tasks that the ISONAS software was previously handling. These include:
Establish and maintain a TCP/IP Socket connection to each reader-controller Periodically send a heartbeat message to each reader-controller.
If stand-alone operation is to be supported, be able to maintain the reader-controller’s stand-alone databases.
The Clock-In software will be responsible for a more detailed handling of the actions of the reader-controller. For example, when a door is unlocked, there are a group of micro-actions that occur.
o The Lower LED is turned Green
o The Lock Control Relay is activated
o A delay for the “Latch Interval” occurs
o The Lower LED is turned Red
o The Lock Control Relay is deactivated.
Previously, when Check-IN was using the TCP/IP interface, this action was a single command, and the ISONAS software took care of the micro-actions. Now the Clock-In software must implement and control these micro-actions.
So Clock-In’s software is a little more involved than before, but this allows the Clock-In software to control the reader-controller with fine granularity. For example, it has full control of the reader-controller’s TTL output lines, which are used to control the companion device’s sound generation.
2.3: SUMMARY.
The TCP/IP interface is a good choice if the associated system does not need the reader-controller to implement special “non-standard” actions. Using the TCP/IP interface results is a faster implementation and is typically easier to accomplish. The integration using the SDK is attractive if the associated system already has all the required who/where/when databases, and there is need for either more detailed control of the reader-controller’s actions or a simplified installation topology at the customer’s site.
