 |
Description  |
|
|
FIELD OF THE
INVENTION
The present invention relates to security systems, and in particular to security systems having centralized operational control and limited distributed control.
BACKGROUND OF THE INVENTION
The nature of security, or access control, systems favors the centralization of all signal reception and authorization controls. However, in view of the variety of situations which are to be covered by a typical security system, control of all
functions directly from a single computer control system becomes unwieldy and impractical for even the most modest systems. Previously, some of the signals could be consolidated in a simple remote module which is connected to the system functions to be
controlled, such as door access and alarm signals, as well as being connected to the central system. However, while remote modules allow the hardware to be expanded, the increased data flow causes a further burden on the central processing computer
system. Moreover, the entire system becomes vulnerable upon a power failure condition at the central computer. Typically, if the central computer power system goes down and the access to system records is maintained only at the central computer, a user
is prevented from being granted entry at the remote unit because access to the database will be suspended during the power-down condition. In addition, breakdown in central/remote communications causes similar problems.
Alternatively, synchronized remote units allow entry to be granted if other remote units fail. However, the flexibility of a practical distributed security system is severely limited, or places a severe requirement on the communication system to
be fast and accurate with the data transferred therein. Moreover, the redundancy of data stored among individual remote units for backup is relatively low, or if provided, causes significantly increased costs. Moreover, the format of the
interconnection and synchronization of the various access control system elements to transfer data presents a problem to the structure of the communication channels, since the various system elements may operate somewhat independently. Furthermore, if
the remote units are communicating to a central unit, the system operations and information exchange rates may be completely independent or at least different, requiring careful synchronization of the system elements or data handshaking protocol to
achieve error-free data transfers.
SUMMARY OF THE INVENTION
The access control system of the present invention provides centralized control of various parameters, listed below. The centralized control is accomplished through the central console, which has two functions. The first is to make the system
operator aware of alarm conditions as they occur, the operator having an opportunity to respond appropriately. The second function is to provide a convenient method of making changes to the system transaction processing equipment (e.g., issuance of new
cards, card cancellations, group reassignments, schedule changes, temporary passes, etc.). This environment is represented internally to the program by a database, and the system provides a substantial repertory of operating commands for maintaining
this database.
The system according to the present invention controls access to areas some of which are more tightly controlled than others, having a higher security level. The system therefore provides a hierarchy of security levels. Each entry and exit
point to that area has an associated card reader and numeric keypad, enclosed in a single housing hereinafter referred to as a card reader unit. The system according to the present invention governs access to a secure area by granting or denying access
requests presented to the respective card reader units. The system responds to a request by keycode alone, request by card alone, or a request by a card followed with a keycode. Typically a card and code are issued to regular employees of the user
organization, and the code-only passes are provided to visitors or those who require a temporary access only. The card codes are unique and invisibly encoded in the respective cards. The code consists of two parts, the first identifying user
organization and the second identifying individual cardholder. Each card is assigned to one or more particular groups. A group comprises a list of reader units and a respective schedule of times at which the particular cardholder will be successfully
acknowledged by the reader units.
The system of the present invention further provides for the grant of access to controlled areas when the central console operation fails by relying on a limited store of information residing in individual card readers of that area.
The individual card readers communicate with the central console system through a polling machine which acquires the card reader data and provides a format of information flow to a first-in-first-out (FIFO) register which communicates with
central processing system. The resulting data flow between the central system and the remote reader is rapid as well as efficient in time and hardware costs. Moreover, the transfer allows completely independent and asynchronous operation of each system
element.
BRIEF DESCRIPTION OF THE DRAWING
These and further features of the present invention will be better understood by reading the following detailed description, taken together with the drawing, wherein:
FIG. 1 is a hardware block diagram of one embodiment of the system according to the present invention;
FIG. 2 is a partial schematic diagram of the network communication board (NCB) and tape control board (TCB) of the system shown in FIG. 1;
FIG. 3 is a partial schematic diagram of a typical card reader shown in FIG. 1;
FIG. 4 is a block diagram of the overall dataflow for the system according to one embodiment of the present invention;
FIG. 5 is a diagram showing the exchange of data for the terminal manager shown in FIG. 4;
FIG. 6 is a diagram showing the exchange of data for the database manager shown in FIG. 4;
FIG. 7 is a diagram showing the exchange of data for the command interpreter shown in FIG. 4;
FIG. 8 is a diagram showing the exchange of data for the transaction processor shown in FIG. 4;
FIG. 9 is a diagram showing the exchange of data for the tape backup and restore module shown in FIG. 4; and
FIG. 10 is a simplified block diagram of the first-in-first-out (FIFO) register of the NCB subsystem shown in FIG. 2.
DETAILED DESCRIPTION OF THE INVENTION
Hardware
The hardward 50 structure of the system according to the present invention is shown in FIG. 1, wherein the majority of the system is included in a console 52 comprising a computer system. The computer system includes a single board computer 54,
typically an iSBC 86/30 computer of Intel, Santa Clara, Calif. 95051, having 128 K of random access memory (RAM) and 32 K of read only memory (ROM). Moreover, the computer further includes an expansion board Intel Model iSBC 428, having a additional
128 K of ROM. The iSBC 86/30 and iSBC 428 are explained in Intel Documents Nos. 144044-001 and 145696-001, incorporated by reference.
Every system console computer 54 includes a battery backup for its RAM, to guard the RAM resident operating database. However, not every system includes a battery backup for general operation, i.e., sufficient to allow normal reader polling to
continue during an interruption of AC power.
The system 50 communicates with the console operator through a display terminal 58, typically a model 50, manufactured by Visual Technology of Tewksbury, Mass. The console communicates with the remaining system hardware and software subsystems
through a network communications board (NCB) 60 having a tape control board 62 residing thereon. The NCB 60 communicates with a printer 64, typically a Mannesman Tally MT-160. The tape control board, receives control commands and transfers data from
the computer system through the NCB 60 to a backup tape cartridge unit 66 manufactured by EPI, Model STR670. The system also receives stored system information from the tape cartridge unit 66 through the tape control board 62 and NCB 60. A plurality of
card readers 70 through 70N are connected in parallel to an RS422 data bus 72.
While the computer 54 and the expansion memory 56 use the particular hardware specified above, alternate hardware may be substituted, the associated software modifications being clearly within the skill of programmers. For instance, the
specified computer modules may be replaced by custom designed computer equipment, or commercial equipment such as the IBM personal computer. With regard to the details of the hardware, the manufacturers of the various integrated circuits used and
discussed below are identified in Appendix VII.
The NCB 60 is shown in FIG. 2, having a connector 82 which receives the tape control board 62, discussed below. The NCB 60 connects to the iSBC 86/30 computer "Multibus" (trademark of Intel Corporation) connection by connector 84. Information
received from the computer 54 includes address, data, and control signals. The Multibus data signals are received on lines 86, comprising 8 parallel data lines, and are received by a bidirectional data transceiver 88, Part. No. 8287. The Multibus
control signals are received on leads 92, comprising parallel signals, and are received by the miscellaneous control and decoder function block 90, to provide the specific sequence of signals required by the format of the iSBC 86/30 Multibus system, as
well as on board signal processing and conditioning. The data transceiver 88 provides a buffered data bus 112 to the subsequent elements, including a programmable baud rate timer 94, Part No. 8253, and associated universal synchronous/asynchronous
receiver/transmitter (USART)96 Part No. 8251A, real time clock 98, Part No. 58174, first-in/first-out (FIFO) registers 100 and 102, Parts No. AM2813, and a programmable interrupt controller 104, Part No. 8259. Similarly, the multiple address signals are
provided on leads 106 to the programmable timer 94, the USART 96 and real time clock 98 to provide programmable selection of the connected elements. The programmable interrupt controller (PIC) 104 receives transmit and receive status signals from the
USART 96 along leads 108, as well as receiving FIFO full and empty signals from registers 100 and 102 over leads 110. The programmable interrupt controller 104 further receives instruction from the data bus 112 in which to order or prioritize the
interrupt signals received on leads 108 and 110 to produce a resulting interrupt signal on lead 114 to the computer 54. The NCB 60 further includes a microprocessor unit (MPU) 120 having an associated ROM 122, RAM 124 comprising Parts Nos. 2732 and
4016 respectively. The microprocessor unit 120 provides address signals from port 0 (PO) along leads 126, wherein additional address locations are indicated by signals received from MPU 120 port 2 (P2) on the data line 128 to address latch 130,
typically Part No. 74374. The data bus 128 provides 8 data paths for information flow, and receives instruction for the MPU 120 from ROM 122 and provides data exchange from RAM 124 thereon. Moreover, data is received from the buffer 132, connected to
FIFO 100 and provides data to the FIFO 102 through buffer 134. Moreover, as discussed in detail elsewhere, the ninth bit stored in the FIFO buffer is used as a processing flag indicating a particular status to the respective processors involved. In
particular, the FIFO 100 receives the ninth bit from the iSBC 86/30 computer along the data bus 112 and transfers that information to the MPU 120 through port 3 (P3). Similarly, the MPU 120 provides the ninth bit to the FIFO 102, which in turn transfers
back to the MPU 120 through buffer 136. Command signals are issued from the computer 54 to the tape control board 150 through data transceiver 8287 and a buffer 136 and thereafter through connector 82.
In the tape controller board (TCB) 62, signals from the iSBC 86/30 computer 54 from leads 86, 92 and 106 are transferred to the board 150 through connector 82, as well as signals from buffer 136 along leads 138. The control signals from leads 92
and 138 are received by a buffer 152. The data signals on lead 86 are received from leads 86 by latch 154, typically Part No. 74245. Similarly, the command and status signals on leads 106 are received by the command and status latches 156, typically
Part No. 74374. The signals from the latches 154 and 156 are connected to form a data bus 158 received by a microprocessing unit (MPU) 160, typically a Part No. 8051 or 8031. The MPU 160 provides address signals on leads 162 from port 0 (PO) as well as
additional address signals from port 2 (P2) through address latch 164. The address signals are received by ROM 166 and RAM 168, typically Parts No. 2732 and 6116 respectively. Moreover, the address signals from leads 62 as well as control signals from
buffer 152 on leads 172 are received by miscellaneous control logic element 170, which selects data input and output functions of the TCB circuit. As with the read only memory 122 on NCB 60, the read only memory 166 TCB 150 provides the control program
for MPU 160. The MPU 160 also provides control signals to the NCB 60 through buffer 152 along leads 174, as well as providing command signals to the tape transport 66 through buffer 178 connected to connector 176 and respective interconnecting leads.
The transfer of byte-wide data to the tape cartridge transport 66 is provided through latches 180 and 182, typically each Part No. 74374, the signal being transferred from the data bus 158 to a data transmission line 184. Previously stored backup data
is received by the computer 54 by data flowing from the tape cartridge unit 66 from leads 184, through latch 180, bus 158, and Multibus latch 155, the latches each comprising Part No. 74374.
In the NCB 60, according to the program stored in the read only memory 122, the MPU 120 processes the information received from the computer 54 from the Multibus and data bus 112, received by the FIFO 100 and in turn by the MPU 120 itself from
data bus 128, into a serial flow of data over the RS422 data bus 72 to the remote car readers 70 through 70N. The RS422 label indicates a known hardware communications line standard. A similar reverse flow of information is provided, wherein signals
received by the MPU 120 from the plurality of remote card readers 70 through 70N on the RS422 data bus 72 is processed into a sequence of parallel words, stored in the FIFO 102 through buffer 134, which is then in turn passed to the computer 54 over the
data bus 112 and following Multibus transceiver 88.
According to the present invention, a typical remote card reader 70 is shown in FIG. 3, which includes a connector and terminal board 190, a power supply and line driver board 192, and card reader subsystem 200. Card reader subsystem 200
includes an MPU 202, receiving the signals from the NCB through the terminal assembly 190 and the buffer assembly 192 on leads 204 and 206, respectively. The MPU 202 processes the signal according to a program stored on the ROM 208, typically Part No.
2764. The MPU 202 provides address signals on leads 210, and additional address signals from the data bus 212, captured by the address latch 214, typically Part No. 74373. In addition, transient information is stored in the non-volatile random access
memory (NVRAM) 216 typically Part No. 2212, also receiving the address signals on leads 210 and data signals on leads 212. The NVRAM 216 is enabled by a signal provided by the 3 to 8 decoder 218, typically Part No. 74138. The MPU 202 communicates with
additional circuits through latch 220, typically Part No. 74374, and drivers 222, 224 and 226, typically each Part No. 74368. The latch 220 provides alarm and control output signals such as a door strike control and duress signal to the external
environment, and the driver 222 receives sensor inputs such as a door ajar signal from the external environment through the assemblies 190 and 192, including known connector and driver elements. Moreover, the driver 222 provides signals to indicator
light emitting diodes (LEDs) 228 and 230, which operate in response to signals entered by the user and the response by the system, discussed below. An eight pole switch 232, retained on board 192 is read by driver 224, for functions described below.
External card user signals are received by the system MPU 202 through the driver 226 from a keypad 234 wherein a sequence of four signals is provided from the MPU 202 port 1, the corresponding orthogonal sense lines being received by the driver 226 and
read therein upon select signal provided by select decoder 218 according to techniques known in the art. Similarly, the drivers 222 and 224, as well as latch 220 are enabled by select signals provided by the decoder 218 according to signals generated by
the MPU 202 and received over the address bus 212. In addition, a four digit seven segment display 236 is provided wherein the segments are driven by a four to seven segment decoder 238 being driven from the MPU 202 port 1 (P1); similarly, the digits
are selected by the remaining four bits of the P1 signals.
The card reader subsystem 200 further includes a card reader coil 240 producing a pulse signal upon presentation of the card 250 as taught by the manufacturer, Sensor Engineering of Hamden, Conn. The pulse signal produced by the coil 240 is
received by a pair of comparators 242 and 244 to detect negative and positive transitions thereof. The transitions are determined by reference to a voltage divider comprising resistors 246, 248, 252 and 254 as shown in FIG. 3 to provide a modest dead
zone in which no comparator output is produced. The voltage divider at midpoint is bypassed to ground by a capacitor 256. Similarly a shunt capacitance 258 and resistance 260 is provided across coil 240 to provide the desired damped pulse response.
The signals from the comparators 242 and 244 are received by MPU 202, which cause the MPU 202 to decode the card 250 code.
The central console system computer 54 selects the particular card reader 70 by address code signals sent through the NCB and data bus 72 to the card readers 70 through 70N. The resulting decoded card code and keypad information is then returned
to the NCB. The console computer 54 responds to the particular request and associated identification codes and either permits or denies entry to the door associated with the card reader 70. Information from the computer 54 will also be presented on the
card reader display 236.
Software
The overall dataflow 50A for the system according to the present invention is shown in FIG. 4. The system of the present invention has hardware which corresponds to the system 50 shown in FIG. 1, wherein a plurality of card readers 70 through
70N containing operation subsystems 70A through 70AN, and reports to a polling machine 60A residing in NCB 60, which processes the card reader 70 through 70N information for retransmittal to a console 52 having a printer 64 and backup tape cartridge unit
66. The console 52 operates according to the system modules contained therein in a computer system 54 as discussed above. The system 50 major blocks contained within the console 52 include a transaction processor 550 discussed in FIG. 8, a data manager
450 discussed in FIG. 6, and a command interpreter 500 discussed in FIG. 7. A terminal manager 400 is discussed in FIG. 8, and a tape backup and restore module 150A (residing in the MPU 160 in the TCU 150), is also included in the system dataflow, FIG.
9.
According to the security system of the present invention, the card records, reader records, group definitions (schedules), temporary pass records, console passcodes, and holidays form a database, defined below. The individual records and
definitions are entered at the system terminal. The optional tape backup is provided to save or restore the database contents on operator command. The system will restart automatically after power failure if the memory data has not been damaged. The
system also provides an operator "load" command, which allows the initial database to be prepared away from the site of an installation and transferred to system memory by a temporarily connected tape unit.
Tape restore, discussed with respect to FIG. 9, is not performed automatically on power up, since the data in the RAM is retained for 48 hours. The operator is prompted if a restore should be done.
Since the system cannot validate transactions on an empty database, the database must contain at least one reader record, one group definition, one password record and one card record. Furnished with this much data, the system is capable of
processing access requests from the one defined card. Until at least one card record exists in its database, the system will deny all card-based access requests on the grounds that it cannot find a record of the card used.
If any temporary passes are defined, the system will accept keycode-based access requests. The use of this temporary-pass mechanism is entirely optional; conceivably, some installations will never use it.
A card record is the basic reference unit for validating all cardholder transactions. The system accepts card numbers in the range 0-32,767 and stores up to 4000 randomly numbered records. Card records are created, revised, displayed, and
cancelled at the system terminal. Each record contains the following items:
Cardcode number
Cardlabel number
Keycode number
Group Assignments Set
Use Limit Number
Use Count Number
Card Monitor Switch
Last Reader Used Number.
The cardcode is the number invisibly encoded into the card; the system uses this as a basic key during validation of access requests. It may have any value from 00000 to 32,767. This value is entered by the operator at the time a card is
issued. Entry into this field is "required" and has no default value.
The cardlabel is the number visible on the card. For reasons of security, there is no fixed relationship between the cardlabel and the cardcode. All displayed or logged references to a card use the cardlabel. The user organization must keep
external records associating employees with cardlabels. The label may have any value from 00000 to 32,767. Entry into this area is required and has no default value.
The keycode is a four-digit number that must be used by the cardholder for all "card and keycode" accesses, and may have any value from 0001 to 9999. It is not necessarily unique for each cardholder, but in most cases will be.
Keycodes are assigned by the operator and may be chosen by the user. However, the system will check the data bases and prevent the assignment of a card keycode with the same value as an existing temporary pass keycode.
The Group Assignments Set identifies all of the groups that govern access requests for the card. The system uses these to validate all access requests for the card, based on the reader and current time of the request.
The Use Limit is a value from 0 to 99 which specifies the maximum daily uses permitted the card at designated readers (see Readers below). If the value is 0 (the default) the system enforces no limit. This limit may be set by the operator when
the card is issued or at any time thereafter. This field is not required, and defaults to a value of "no limit."
The Use Count counts the actual uses: only valid accesses apply against the specified limit. It is reset at the beginning of each day. The operator cannot write into this field; only the system writes into it. The operator may reset this field
to zero on one or all cards.
The Card Monitor Switch is either OFF, or ON (access), or ON (no access). Normally it is off; when it has either of the two ON values (by operator command), every use of the card is announced at the system terminal as an alarm message. This
field is not required; the default value is OFF.
The Last Reader Accessed field records the number of the last reader at which the system granted a valid access to this card. The system uses this value, together with certain reader attributes (see section four of this chapter), to perform
antipassback testing. Normally, this field cannot be set by the system operator, though it may be displayed. There is, however, a reset command for special situations.
Exactly one reader record must exist in the database for each installed physical reader unit in a given installation. A reader, as stored in the system database, has the following attributes:
Address
Keycode-Required Switch
Use-Limit Applied Switch
Antipassback Test Switch
Precedeset.
The reader Address is physically set at the reader unit; it is not programmable from the console. At initialization, the system itself determines the physical addresses of all the readers currently responding, and warns if any of the database
reader records does not have a corresponding physical reader.
The Keycode-Required Switch is either ON and OFF. When the switch is ON, the system will require a keycode with every card-based access request. This access mode is programmable by the operator.
The Antipassback Test Switch is either ON or OFF. If is programmable by the operator. If this value is ON, the system performs antipassback testing on each access request at this reader.
Precedeset identifies only those readers that may immediately precede access to this reader, as determined by their physical location. Since the system uses this set, together with the Last Reader Accessed field in the card records, to perform
antipassback testing, the set must be defined for any reader whose Antipassback Test Switch is ON. It is programmable from the terminal, but is normally not revised except after changes in reader location or building configuration (i.e. remodeling).
A Group is a schedule and a set of readers. The system holds up to 32 group definitions, entered at the system terminal. A group is defined by simply listing the readers in its set, and defining the schedule associated with the group. Each
group has an identifying number from 1 to 32. Once defined, a group may in turn be associated (by means of its identification number) with one or more cardholders, to govern the times and readers at which the cardholders will be granted access to
secured areas. Within a group, all reader accesses are governed identically by the group schedule.
The group schedule consists of 10 "micro-schedules." Each micro-schedule defines a single time period (by its start and end times), and assigns this period to any combination of eight days (the seven days of the week plus a generic "holiday").
Temporary passes may be created, displayed, and cancelled at the system terminal; only the group assignment set, identification number, and expiration date may be revised.
A temporary pass consists of the following items: (1) Keycode number, (2) Group Assignments set with optional ID number, and (3) Expiration Date.
The Keycode is an arbitrary value from 0001 to 9999, excluding any value that is in use as a card keycode. It is supplied by the operator and may be specified by the user.
The Group Assignments set is identical in format and purpose to the group assignments set defined above for card records. The optional ID may be used, at the discretion of the user organization, to tag the temporary pass keycode with a
five-digit identifying number (less than 32,767). If the field is present, the system will include it in all reports that reference the pass. The ID has no internal significance to the system.
The Expiration Date is the last date on which the temporary pass will be honored by the system. Technically, it expires at the end of that day; the effective expiration time will be governed by its group assignments. A default value to the
expiration date is the current date.
The transaction processor 550 of FIG. 8 monitors all installed readers for incoming access requests. A request begins when someone either (a) presses a sequence of digit keys, or (b) runs a card through the slot. The system concludes every
transaction by either (a) unlocking the door at the reader involved, (b) leaving the door locked and displaying an alarm message at the system terminal, or (c) aborting the transaction, e.g., if the person abondons his request.
At some readers, the system may require only a card; at others, it may also require an auxiliary keycode. In general, keycodes (without a card) provide only a low level of security, and are therefore defined only as temporary passes rather than
as reader attributes. The system logs all normal transactions on the printer, if one is present, through the terminal manager 400 of FIG. 5. Information is transferred between the system console and the polling machine by a serial data connection 72
defined in FIGS. 2, 3, and 10.
There are two types of alarms: hardware-related and access-related. Hardware alarms originate in such conditions as tampers, communication problems, door left open ("door ajar"), and so on. Access-related alarms originate with anomalous access
requests, i.e., at the wrong time, at the wrong reader, unrecognized keycode, and so on.
The "point of detection" for various alarms may be almost anywhere within the transaction-handling mechanisms. Some hardware-related alarms, such as a card reader tamper alarm for example, are detected at the reader units. Others, such as
communication problems, are detected by the polling-machine program that drives the communication board.
Of the access-related alarms, most are detected by system software when it compares the access-request information with the relevant contents of the operating database. A few are detacted at the reader; in particular, when access depends on
entry of a correct keycode in addition to a valid card, it is the reader unit that compares the required keycode sequence (sent down from the system console) with the one actually entered.
Regardless of the point of detection, all alarm reports are displayed at the operator's option at the system terminal to be announced to, and acknowledged by, the system operator.
Each card in the system may be individually use-limited. A software switch on each reader determines the applicability of the use limit to that reader. The specified use limit for each card applies only at readers whose use limit switch in ON.
The limit is cumulative for all such readers; it does not distinguish one reader from another.
Any secured area may be subject to antipassback checking. All such testing is performed entirely by software, and is completely programmable from the console. Areas may be nested, changed, and reconfigured at will, subject only to the following
constraints: (a) every access path into and out of the area must be under system control; and (b) temporary passes (i.e. keycode-only accesses) are not allowed into the area.
The actual test uses the Last Reader Accessed field in card records, and the Precedeset and Antipass Switch fields in each reader record. The algorithm used is perfectly general, and does not require readers to be explicitly designated as IN or
OUT.
The operating subsystem reader unit 70A through 70AN consists of two input devices having a slot to receive a card and a numeric keypad to enter keycodes. The reader unit 70 through 70N has three visual feedback devices: a red LED, a green LED,
and a numeric LED display (228, 230, and 236 of FIG. 3, respectively). Anyone may request access to a secured area by approaching a reader unit and either running a card through the card slot, or entering a keycode on the numeric keypad. The first of
these are called "card-based requests," and the second is "code-based requests." Each of them is discussed separately below. Regardless of the request type, however, the person who has requested access will see, within two seconds, either the red LED,
indicating his request is denied, or the green LED, indicating his request is accepted and the door is unlocked, or a prompt indicating that he is to enter a four-digit keycode for further validation of his request.
In the latter case, if he enters the correct keycode, the reader will give him a green LED and unlock the door. If he enters an incorrect keycode, the reader will show him the red LED, and allow him additional tries, according to a count that is
programmable from the console. If he has not entered a correct keycode at the end of the attempt countdown, the system announces an alarm and aborts the entire access request. Whenever the reader in not looking for or accepting a keycode, its numeric
LED display shows the current time.
When a card is presented, the following conditions must be fulfilled before the system will grant an access to the respective areas controlled in order from the simplest to the most complex.
A card presented from another system (not shown) will be unconditionally rejected. If communications between the reader and the system console 54 were interrupted, the reader unit can be configured to pass the card on the basis of its system
code alone, since none of the more complex tests below can be performed. Whether an individual reader in "degraded" mode will pass or reject a card with the correct system code is programmable by the operator. If the card used passes the "system-card"
test, the system database will be interrogated for a record of this card. If none exists, the system will deny the access request and announce an alarm. Even if the system has a record of this card, there are two cases in which it may nonetheless
create an alarm and/or end the transaction.
The database record of each card contains a three-value field whose values are not alarm, alarm/access, and alarm/no access.
If this flag is set to alarm/access, the system will announce an alarm but continue normal processing of the request; but if it is set to alarm/no access (which will happen if it has been reported to the system operator as a "lost card"), there
is no reason to perform any further tests; the system denies the access request and announces an alarm.
So far the system 50 has established that the card belongs to this installation and has been validly issued. Next, it tests whether access of the current reader is permitted at the current time. It does this by testing, in turn, each of the
groups (as many as 32) to which the card presented is assigned. If the current reader, and the current time, are found in any one of these group definitions, then the group assignment test is passed.
Each group to which the card is assigned has a list of readers which may be used. If the reader used is on this list, the system continues on to the next test; otherwise it announces an alarm and denies the access request.
Each assigned group also has schedule times during which access may be validly requested. The system attempts to find a slot, among those comprising the schedule, that includes the current time. If it fails, it sends an alarm to the terminal
and denies the access request; otherwise it passes on to the next test.
In the card record is a number that specifies the maximum accesses allowed each day. In the record of each reader, there is a flag that identifies the reader as a use-limited reader. If the current reader is a use-limited reader, the system
counts the access request against the limit in the card record, and if this count exceeds the number stored in the card record, denies further access requests for the rest of the day, and sends an alarm to the terminal each time the card is presented.
The reader to which the card is presented may have been designated, in the system database, as an "antipassback" reader. If it is, then the system will check whether it was physically possible for the user to get to this reader from the last
reader used. If it was impossible, then the system deduces that the card was "passed back" to another user, sends an alarm to the terminal, and denies the access request.
The system checks into its records for the reader used, to find whether it must also request a keycode, or whether the card alone is sufficient to gain access. Note that this question is answered on a reader-by-reader basis. If the access
method is "card-only", then the system commands the reader to unlock the door. The reader signals this with a green light, and the user enters. (The system waits a certain amount of time for an indication from the reader that the door in fact was
opened; if no indication exists, it assumes that the user intends to abort, and aborts the entire transaction and announces an alarm.)
If the system finds that the designated access mode for this reader is "card plus keycode," then it looks into the card record for a four-digit keycode, and sends it down to the reader with instructions to wait for a keycode from the user,
compares it with the one it has just received, and grants or denies access based on the results of the comparison. If the keycode entered matches the one stored in the card record, the reader unlocks the door and waits for the user to pass through. If
the keycode entered does not match, the reader allows a (programmable) number of additional tries before sending an alarm up to the console; the door remains locked.
All transactions that begin with a keycode are handled by the system 50 by a "temporary pass" mechanism. The system first checks the current reader entry in the reader table to see if it is an "antipassback" reader. If it is, no temporary pass
transactions are allowed, and the system sends an alarm to the terminal and denies the access request. When a four-digit keycode is entered, the system attempts to locate a number corresponding to this keycode in its table of temporary passes. If it
does not find such a number, the request is denied immediately, and sends an alarm to the terminal. If the system finds a keycode, it may have associated with it a set of group assignments. In this case, the system will perform the usual reader/time
validation sequence.
The keycode record may have associated with it both a set of group assignments and an individual identification number, representing perhaps a guest, visitor, or temporary employee. The system handles this as in the preceding paragraph, but
includes the identification number in the report.
In special situations, the system operator may issue a command at any time that has the effect of unlocking a reader-controlled door for an amount of time that is also programmable. Moreover, some doors may have a pushbutton 191, FIG. 3, mounted
on the opposite side from the side that is governed by a reader unit. The pushbutton unlocks the door with strike 193, and the reader 70 signals the console 52 when this happens.
Whenever the reader prompts for a keycode, the cardholder may precede his keycode with a special digit to indicate duress.
The system, especially the operator interface, is designed in such a way as to make large classes of operator errors impossible. It is impossible, within the present system, to reference groups, cards, schedules, readers, etc., which do not
exist; it is impossible to enter syntactically inappropriate data values; it is impossible to place the screen cursor at an undefined location; and all keystrokes that do not have a defined role, for any given state of the system, are ignored.
A cardholder requesting access at a reacer whose designated access mode is "card plus keycode" may enter a programmable number of erroneous codes in a row before the system reports an alarm. A "clear" key is available to him to allow escape from
an erroneous digit entry. On any transaction, the cardholder may change his mind even after the system has given him a green light; the system will time out waiting for a signal that the door has actually opened, and abort the transaction. The control
program is capable of detecting a number of nonfatal errors, especially in communication between modules 70 through 70N and NCB 60.
A console operator with the proper level of access can place one reader in "testmode." This allows the console operator to diagnose problems with a reader and to issue specific polling machine level commands directly to the reader and to see the
results, in Octal code, reflected back on the system console.
Clock Interface
The clock interface is responsible for all time-keeping functions of the present system.
The clock interface actually consists of two separate clocks. The first clock is a hardware clock 98, a National Semiconductor MM58174 CMOS clock chip, located on the network control board (NCB) 60 of FIG. 3. The second clock is a software
clock, an interrupt routine driven by a 1-Hz output of the power supply. Both interact to give the correct time even in the event of a power outage.
The MM58174 clock chip 98 is even-addressed (I/O locations) from 20OH through 21EH. These ports correspond to the following chip resisters:
200: test (write only)
202: tenths of seconds (read only)
204: units of seconds (read only)
206: tens of seconds (read only)
208: units of minutes
20A: tens of minutes
20C: units of hours
20E: tens of hours
210: units of days
212: tens of days
214: days of week (1-7)
216: units of months
218: tens of months
21A: year/leap year (write only)
21C: start/stop (write only)
21E: interrupt/status.
During normal operation, the test register (200H) should be set to 0, and the start/stop register should be set to 1 (running). Note that several registers are either read only or write only. The seconds registers are read only, and are reset
whenever the clock is stopped. Since the clock must be stopped to set the day or date, the seconds are reset whenever the day or date is set. The year/leap year register is a write only register, whose contents indicates the occurrence of a leap year.
The interrupt-driven software clock is driven by the 1-Hz signal from the power supply, and tied to the interrupt level 7 of the NCB 60 slave 8259A 104 programmer interrupt controller chip (PIC). Every second, the interrupt updates the following
software registers: second, minute, and hour. Once a day, at 30 minutes, 0 seconds past midnight, the software timer updates the CMOS clock chip. Therefore, the clock chip is not allowed to drift over more than one day, resulting in a maximum time
error on the order of several seconds.
There are four main software entry points to the clock interface: set time, get time, set date, and get date. All of these entry points consist of parameterized function calls.
The 1-Hz clock interrupt is tied to interrupt input 3 of the slave PIC 104 on the NCB. The associated interrupt handler consists of several nested do loops which increment the second, minute, and/or hour memory locations. At 30 minutes, 0
seconds past midnight, these memory locations are used to update the registers in the CMOS clock chip. Finally, the handler executes an "rq$exit$interrupt" system call.
Terminal Interface
Terminal interface software of FIG. 5 transfers data between the system terminal manager (TM)400 and the system console terminal 58. If buffers data in both directions; up to 255 characters from the keyboard, and up to 1023 characters out to the
display. Because data input is interrupt-driven, type-ahead can be (and is) utilized by the TM.
The terminal driver interfaces | | |
