Hi, welcome to the ninth paper on access control. This session we continue with unit four and will be looking at software operation for single door controllers.
Single door controller software
Generally the features common to all systems deal with the storage, processing and reporting of details and events relating to the users of the system. Identification of devices such as card readers, any type of token, regardless of how sophisticated, all need to be programmed with information to enable them to determine if the person standing at the door trying to gain access is authorised or not. This information will normally be held in a list of valid token numbers.
This list is, as the name implies, a list of all tokens valid for use on the system. To ease administration a token number may be associated with a name to speed recognition of the token holder to whom the number has been allocated.
In most systems the list of valid tokens may just be a range of token numbers that have been validated for use on the system. For instance, if the range of token numbers valid for use is 10,000 to 10,100, this would allow anyone who uses a token whose number lies between 10,000 and 10,100 to be granted access while anyone whose token number lies outside this range will be refused entry.
In the more complex systems the information about who holds the token can be programmed into the system which, thus, requires a keyboard and screen included in the system (although these may later be removed following completion of programming).
There are basically two methods of storing token holder information.
1. Store the information in the token's code.
2. Storing the information in the controller memory.
In the first instance the amount of information that can be stored is small due to the limited storage capacity of tokens. It is also impractical for tokens whose data is embedded during the manufacturing stage, such as the weigand cards. In systems where data is held in controller memory, the amount of information that can be stored is small due to the limited storage capacity of tokens. It is also impractical for tokens whose data is embedded during the manufacturing stage, such as weigand cards.
In systems where data is held in controller memory, the amount of information stored about a token holder is theoretically limitless, although in order to reduce the amount of memory the system needs, most systems provide you with only two or three entries per token.
The type of information you might want to hold about a person: Since tokens need to be programmed into the system, it is very easy to change user details. This offers a security advantage over the pre-programmed cards as lost cards can be invalidated by removing them from the list of tokens that the system recognises. However, the programmability of user details also represents a security risk. The risk is that if a person can easily be programmed into the system then it is possible for someone to re-program the system so that their token is valid for use through the door.
The easiest way of reducing the chances of this happening is to place the equipment that enables token programming in a highly secure area. However, this may prove impractical.
For systems that are programmed via the controller password protection or special programming, tokens which must be entered before programming can commence are provided, so that only authorised personnel are able to change token data. For security purposes the password for tokens themselves are normally held only by someone with the highest security clearance and will be securely stored. As an added security feature some systems can store an audit log of changes which can be sent to a printer for security checking. Systems that support reprogrammable token information are also able to offer facilities other than the simple recording of permanent staff details. The most common additional feature is the issuing of visitor cards suitable for a variety of different visitor situations such as: 'N' use tokens: Token able to be read 'n' times before they become invalid.
Time Tokens: Tokens useable for a given number of hours or days (useful for contract labour).
One of the problems with dealing with programmable tokens is differentiating one token from another. To ease this task token vendors mark tokens with an external token number which is an administrative serial number printed on the back of each token and will usually be uniquely identifiable for that site. As well as an external printed number, tokens will also have an internal token number which is the identity number encoded into the token at the manufacturing stage. This code should, for security reasons, never be the same as the external number and will be the only number recognised by the system.
The internally encoded number may also incorporate a site code or facility code prefix which will be the same for all tokens on a\ particular site, and will ensure that if an internal token number is duplicated for another system it will not be recognised on a different site.
Another approach is to ensure that the internal code capacity of a token is sufficiently large that a token number need never be duplicated, no matter how many tokens are issued. With this approach, the site code is not required.
Time based entry
A feature which is now common in programmable single door access control systems is time based entry. Basically, this allows the site owner to program a series of times during which certain categories of staff can gain entry. The most common method that manufacturers use to offer this facility is through the provision of a number of time codes. The time code consists of a start and end time for specified days of the week. By associating a time code with a token , it is possible to restrict the hours and days of the week during which access can be gained.
In the simplest systems there will be only a single time code which governs all token holders. More advanced systems will offer a number of different codes that can individually be configured for different categories of staff. Unfortunately, a simple list of start and finish times is not sufficient to control the times at which staff may gain access to a site. \There are three further factors which we must address.
1. What day will the staff be allowed access?
2. Will access be allowed on holidays/.
3. What if staff are to work overtime? In response to question 1, most systems that offer time-based entry facility will provide the opportunity to specify the days during which entry can be gained.
Fewer single door controllers offer the facility to allow different access criteria on holidays. This is largely due to the logistics of programming the controller to recognise which days of the year are public holidays.
Rarer still is any allowance for overtime working. This, however, rarely causes a problem as staff are normally exiting premises only during such periods, and few single door controllers offer token or card controlled exiting as well as entry. In some systems a time coder will be associated with a reader so that the reader used will determine the times at which access can be granted
Printed Events
Many access control systems provide the facility to print events as they happen onto an attached printer. The information printed may just be illegal events, called 'exceptions' (invalid token, invalid PIN code, door propped open, etc) or may include all events such as normal entries and exits. Normally only the illegal events are printed, which saves paper and keeps an easy to read copy of al unusual events on a given day.
Input/output programming
Controllers that offer general inputs and outputs will provide logic by which the system can, in response to an input, switch an output to annunciate or indicate an event or an alarm.
In the simplest systems there is no flexibility in the programming with input 1 activating output 1, input 2 activating output 2 etc. Such an arrangement, despite its apparent simplicity, can be used to implement sophisticated switching arrangements.
Controllers of greater complexity offer the facility to programme inputs and outputs individually and may offer an range of actions that an input or output can trigger such as unlocking the door (during fire alarms) and locking the door (intruder alarms) Once again we've come to the end of this session. I hope its been useful to you. Next month we will be looking at Operation and Architecture of Multi Door Systems.
1851 — The facts
Source
Security Installer
