Printer Friendly

The latest badge of courage.

WITH THE INTRODUCTION OF electronic photoimaging ID systems in the 1980s, physical security departments were faced with the problem of supporting yet another computerized system separate from and independent of the electronic access control systems they already had installed. Although the photoimaging ID systems gave a new level of control to card issuance, they also created a problem of administering yet another electronic data base.

Electronic photoimaging ID systems were pioneered in the mid 1980s by companies whose main business was not electronic access control. Instead, companies who specialized in electronic color imaging offered strictly badging systems. These systems have been primarily implemented in the PC environment, using standard PC communication packages, such as Novell software running on a token ring local area network (LAN).

Access control systems, on the other hand, were evolving on computers from traditional minicomputers, such as PDP-11s and VAXs, to the Risc and 386/486 platforms operating under several different types of Unix.

These systems were normally comprised of dumb terminals that accessed a single host station. Their purpose was to maintain all exit and entry activities of a particular facility by using the card produced by the badging system.

The fact remained, however, that each of the above systems ran from its own data base. Each of these data bases contained independent copies of cardholder information. The physical security manager was forced to be a systems operation manager as he or she juggled two data bases with the following problems:

* Cardholder information must be entered twice.

* Two independent networks must be installed and supported.

* Two systems had to be administered (that is, tape backup).

* The data on two systems had to be synchronized.

* Vulnerability existed in every lost or stolen card situation.

* Two independent systems had to be supported and paid for in yearly maintenance contracts.

After the systems were installed, the physical security/systems operations manager began to dream of an integrated system with the following features:

* default access rights that are assigned upon card issuance,

* photos that are accessible from the access control system,

* access rights that are available from the badging system,

* one system to administer and support,

* the ability to use the badging system for access control in case of failure and vice versa, and

* visual verification of enrollees by using CCTV technology and previously stored badge images.

Solution 1: Sneaker net synchronization. (See Exhibit 1.) The simplest form of integration is to periodically--daily or weekly--write all data that has changed on one system to floppy disk or tape and load those changes onto the other system. Most access control and badging systems come with an ASCII file import-and-export feature that can be used to accomplish this.

The data base design should include a date and time field to indicate the last time the record was changed. The export should be designed to select all records that have changed since a specific date.

The simplest export file format is one record per line with fields of fixed length. For example, the file format might be as in Exhibit 2.

With this method of integration, the synchronization problem you are trying to resolve should be carefully examined.

For example, if you are trying to eliminate the entry of employee information twice, you could make the badging system the master by entering cardholder information. Then export the changed data to floppy and import it onto the access control system. This would probably result in the most efficient solution. Although this method simplifies data entry, it requires extremely good operational procedures to prevent data from being entered on the slave system.

On the other hand, if you are trying to synchronize card information without duplicate entry, the export file must be expanded to include an action field at the beginning of each record that would indicate whether it is an add, change, or delete transaction.

For example, the first character on each line could be either an A, C, or D for add, change, or delete, respectively. This goes beyond most standard import and export features and is likely to require custom programming by each of the system's vendors.

If changes to employee information on each system are to be permitted, the security manager should decide how conflicts should be recognized and resolved. As an example, a conflict could occur if different changes to an employee's data are made on both systems and then exports are run on each system to be loaded on the other. The result would be for the systems merely to exchange employee information and yet still be out of sync.

This level of integration has problems with timeliness of updates. Weekly or even daily exchanges of data will not help in cases of card theft or employee termination. Updating only one system and waiting for it to be propagated to the other system can lead to disastrous breaches in security. The only protection against these types of events is a real-time synchronization of systems and a tighter level of integration.

Solution 2: Asynchronous real-time synchronization. (See Exhibit 3.) In this solution, the two systems are physically connected via a wire over which data is exchanged. A modem will be required on each side of the wire if it is longer then 50 feet.

When designing this solution, you need to consider the physical connection (RS-232), the transport protocol (x-modem), and the packet content. The physical connection and transport protocol are defined by standards documents where the packet content must be defined by the system designer.

These systems send updates to each other, one transaction at a time. Each transaction consists of a transaction type, for example, EA-employee add or CC-card status change, and the data needed to complete the transaction.

The actual content of the data might change depending on the type of transaction. For example, an employee add transaction would require all of the employee information, whereas a card status change would require only the card number and the new status.

This solution calls for close cooperation between the programming resources of different system vendors. It is likely that the field types and sizes used by the two systems differ, so a detailed specification of the data that is going to be exchanged between systems and how the data is going to be formatted will be required. Working this specification out can take anywhere from four to 10 weeks of development time by each vendor.

In addition, allow time for integration testing. Changes after installation will be hard to obtain because of coordination problems when dealing with two vendors.

The design should allow for buffering transactions if one of the systems goes down or the communication line is lost. The buffered information would be sent as soon as both systems were running again.

Note that a two-way conversation might not be possible with some DOS-based badging systems because DOS can run only one task at a time. A terminate and stay resident program would solve the problem, but the memory constraints of the DOS environment often prevent such implementations.

The asynchronous real-time synchronization solves the timeliness of updates on both systems but does not resolve synchronization problems. Although we have narrowed the window where changes made on both systems occur at the same time, the two data bases, during the process of swapping information, may still be out of sync.

Also, we have not addressed synchronization problems when backup tapes must be used to restore a crashed system. Multisystem administration headaches are still present and any integrated system features are unavailable.

Solution 3: Common data base, common operating environment. All of the problems outlined earlier are solved when the access control and badging systems are networked using a LAN or wide area network, share a common data base, and run under the same operating environment.

Data entered by one station on the network is immediately available to all other stations via the common data base. Also, the common data base ensures that employee or card data being changed is locked during that time, so synchronization is not a problem. Vulnerability in lost or stolen card situations are now eliminated because any station can make this known immediately by changing the common data base.

The single networked system means that system administrative functions can be made from a single station on the net and need to be done only once. Also, tape restore brings all systems back to a common point in the event of catastrophic failure.

With the two systems now completely integrated, we can focus on satisfying the wish list of integrated features outlined in the beginning.

* Default access rights can be assigned on card issuance because the badging system now has access via the common data base to the set of access levels defined by the access control system.

* Employee and passholder photos are accessible via the network and can be displayed on any image capable system, regardless of whether it is badging or access control.

* The badging systems can directly access the common data base to display the access privileges for any card.

* Since only one data base is available, system administration tasks need be done only once.

* Because each station is running the same operating environment the badging programs can run on the access control system and vice versa. Certain interface hardware might be required to make this completely true.

* Visual verification of cardholders is possible because reader swipe events and cardholder pictures are available on the same machine.

The common operating environment also opens up other possibilities. For example, third-party applications, such as electronic mail, may be purchased and run on all systems on the network.

Several different levels of access control and badging system integration have been presented. The solution chosen depends on the security level required, with the highest being provided by the totally integrated solution. The first two solutions require working with two systems vendors to provide some form of system synchronization. The last allows for the two systems to become one.

The completely integrated solution was found to have the following advantages:

* immediate change propagation,

* consolidation of information,

* centralized control of the system,

* greater security,

* better disaster recovery,

* possibility of distributed computing systems, and

* minimization of maintenance

tasks.

Today's access control industry is on the verge of another great phase of evolution. With the advent of running both systems in concert on a shared data base, the time has arrived in which the security marketplace will begin to think of its access control products synonymously with the leading edge technology found in the badging world.

Donald J. Culeton is software manager of EDICON Systems Division, a division of Eastman Technology Inc., which is a subsidiary of the Kodak Company, in Rochester, NY.
COPYRIGHT 1992 American Society for Industrial Security
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1992 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:System Integration; computer system aids identification systems
Author:Culeton, Donald J.
Publication:Security Management
Date:Aug 1, 1992
Words:1784
Previous Article:Reading, writing, and intervention.
Next Article:Making the cinema safe at showtime.
Topics:


Related Articles
You've come a long way, badges.
The new image of corporate badging.
Computing a successful system.
Security works: time sensitive.
Setting your sites on security.
Read all about it.
Merger, they wrote.
Revisiting Visitor Badging.
When visitors become ghosts. (Working Wise).

Terms of use | Copyright © 2016 Farlex, Inc. | Feedback | For webmasters