Door Objects for Access Control
By: Ed Chandler, CPP

It happened again yesterday. We were talking about a new project. The manufacturer that we wanted to use did not have, as part of their standard offering, a feature of door control that we would need. The site has several existing motorized revolving doors that are access controlled. The clean antipassback operation of these doors is critical to the success of the access control design. How should we proceed?

A concept has been forming for several years now that will allow greater flexibility for systems, simplicity of the setup programming, and a more realistic approach to the financial aspects of modifying the microcode that makes an access control door function. One size does not fit all in terms of the doors that are programmed into an access control system. The manufacturers continue to present reader or door screens with lots of options, switches, and relationships, and still we often need more to satisfy a clean installation. Because there were many different styles of airport jetway doors implemented during the big FAR107.14 days, many of the manufacturers created one or more separate subprograms called jetway doors. That is an example of a door object. Why not design the systems from the ground up with door objects?

The access control industry is not properly positioned to meet the customer needs for door operations. Even with some of the largest manufacturers, we have waited years for them to include a function that will allow us to lower the false alarm count from specific door applications. This is not because these manufacturers don’t see the use or the need for the requests. It is because every piece of software that is written into the systems is a business decision that must be weighed against other priorities. And, it is not easy to change the "one size fits all" code for a single case without affecting all of the other applications that are already installed.

This article presents a future concept, not a fait accompli. Some manufacturers are close to having door objects.  Let’s get the access control industry out of the microcode business, at least in terms of how a door operates. It is clear that the industry does not make a profit on that portion of their enterprise, a fact that is probably the driving factor in the intransigence of door operation changes. Most of the industry will be designing with some form of door objects soon, simply because the economic case is so strong. Implementation of this concept will allow for almost infinite flexibility while not being constrained by legacy code and the "one size fits all" constraints. To put all of this in perspective, let’s look at a short history of the industry.

History

The first versions of access control used early CPUs with several readers connected to multiplex communication boxes. As systems grew, the communications strategies became more complex, unwieldy, and slow. The industry moved to distributed processors that could make the access decisions promptly and subsequently transmit the history of the transactions back to the central systems. These distributed processors were set up to store card numbers, access criteria for the doors that are served by them, and some number of historical transactions. The history was added for the case where the communication line is lost to the central CPU (host computer) or if the system is using dial-up communication. Since all of the manufacturers call their distributed processors by different names, I will use the generic term Smart Remote Box (SRB) for these distributed processors.

Along with the complexity of the SRBs came the full interaction of access control systems with alarms for the access controlled doors. An alarm contact on a card-in/free-exit door must be shunted for valid transactions.  When entering, a valid card read will shunt the alarm.  When exiting, various devices that will automatically detect a person that was exiting are used. These devices are typically called a REX, which stands for Request to Exit. The process of accurately determining when a door is secure, in transition, held open, or in a forced open state continues to be a challenge today.

Attempts at false alarm reduction continue to be made by the users of large systems. Many large systems today have more false door forced alarms and too many door held alarms to allow the central monitoring area to function appropriately. There are only so many calls to which a given set of rovers can respond. And it is useless to spend the dollars for a rover to respond to a false signal from the system. There is a great economic need to clean up this part of the access control industry. There are enough differences in the various doors and hardware that are served by any manufacturer’s systems that all of the possible scenarios of operation have not been fully considered in the design. Thus, there is a need for operational change. Getting the manufacturers to make these changes is difficult because it is very expensive to do safely and correctly. The ramifications are great.

The microcode structure that defines the SRB actions at a particular door have historically been stored in Programmable Read Only Memory (PROM). To change the code in a PROM, the chip must be replaced, thus requiring physically visiting each SRB. In the last few years, FLASH memory has become available which allows the microcode program in the SRB to be downloaded from the host without the need to physically visit each SRB. With flash memory, the process of changing the operation of an SRB is much more efficient. Flash memory has made it possible to accomplish a door object based microcode download from the host computer.

Economic Perspective

Security is big business today. However, the  industry has some inherent economic challenges. Any medium sized commercial software company will sell thousands of one program, and a large software company will sell millions of copies. Yet, even the largest access control companies sell only hundreds, or fewer, of any one large system software product. Large systems can be considered to be those with greater than 256 readers. These programs are complex and require many lines of code, perhaps as many as 500,000 lines.

Programmers can only produce so many lines of code per year, yet each line of code costs the same to both the large software company and access control company. Microsoft has said that NT is over 20 million lines of code.  Therefore, the return on investment per line of code is hundreds to thousands of times greater for the commercial software company than for the access control company. The difference is made up by all of the hardware sales in the security world. The fact remains that changing the software to fix a slight anomaly in a timer for a door cannot easily be justified on a "return on investment" basis. Money is lost on every change, and changes are made only because of the long term goal of having a good system and good customer relations.

The biggest single cost when changing SRB microcode is the engineering and testing to make sure that the change will not adversly affect the installed base of doors.  I call this the legacy code cost.   The door objects concept eliminates this cost because a newly created door object would only affect the doors to which it is applied.

Flexibility of Door Objects

One solution to the high cost of microcode changes is to utilize an "engine" that has field adaptable code. The process control and Supervisory Control and Data Acquisition (SCADA) ndustries have developed around this format, and the building management industry is generally heading in this direction. A relatively generic product "engine" would be provided to the installing contractor.Microsoft Operating Systems:

Libraries of functionality would also be provided to the contractor to facilitate the implementation work. There would be no need to try to make one solution fit all cases if the generic engine allows the installing contractor to modify the microcode to fit the customer’s physical and operational needs. This is the basis for a "door object" in the access control industry.

Systems are typically installed with sets of similar doors. If, on a site, there are several buildings, typically all of the lobbies will be configured in the same way. The same is true of all of the access controlled perimeter non-lobby doors and other groups of portal types for the buildings. Included in the list are alarmed doors that may have local sounders or other attributes. The timers will be different for each type of door, but the initial default time may logically be the same. Even with all the similarity, there is still a need to be able to uniquely adjust virtually every timer in the system. One example is the case where one door that is functionally similar to another may architecturally need to have the reader placed farther from the door.  In this case, the unlocking should be set to a longer time.  Each set of similar doors will be a door object.  The timers within the object will have a default setting, and each individual door will be able to either use the default or be adjusted to suit the unique conditions.

Without making unrecognizable changes to the access control products that exist today, it would be possible to format the systems with door objects. Initial libraries can be shipped with the systems. These could include:

The list will be quite long. The ability to create new objects to add to the initial set will be central to the success of this process. Possibly, some of the library of objects could be sold at additional cost. A jetway door and a mantrap are two specialized objects that come to mind.

Door Objects as the Solution to Ease of Programming

One of the industry’s difficulties today is the complexity of the user programming of the doors. The application screen for a reader or door has become very complex to accommodate all of the variations that have been programmed into the systems. In contrast, the screen for a door object can be as simple as the door that it represents. To add a door, the operator simply will pick the object that is appropriate to the physical and operational need of the door. This object will then be presented on the screen with a choice to self configure or to allow the operator to assign the actual point addresses for each reader, input, and output. The object’s default times will be used for each of the timer values, while also allowing each of these to be user changeable. This process will greatly simplify the user programming of the system.

When a condition is found where there is no door object that meets the needs of the operator, a new object will be able to be created. Depending on the implementation, this may be a relatively simple process or one that is complex requiring a special training class. The installing contractor or the very sophisticated end user would be typical of a person authorized to create a new object. There may also be some hardware and/or software costs. If all of the door object creation code can be integrated into the access control application, then the capability could be locked out of the system without the use of an appropriate password. The name of the person creating a new door object could be attached to the object for control purposes. Scratch creation of a new door object is needed, as well as the ability to take an existing object and do a "save as" to a new name and modify the former object with new functionality. It would be wise to lock out the ability to change the initial library, other than for the timer default settings.

The logic modules for door objects in an SRB will probably need to be compiled. This will be true of any design that uses compiled door objects instead of a somewhat less flexible table driven approach. To handle the compilation, one approach is for the manufacturer to provide a WEB site, with appropriate controls that would allow the same set of sophisticated installing contractors and end users to log into the site. These authorized persons would be the ones to create the object at the manufacturer, get the manufacturer’s compiler to compile the object, and then file transfer the finished code back to them. This approach would save potentially ten to fifteen thousand dollars per group that would be able to create objects.

The main concept of the door object is that the manufacturer would be creating a standard product that does not require modification by the manufacturer to meet all of the physical and operational conditions of the site. Such needs are constantly changing.

The sphere of influence of an SRB should be the same as that of a door object. This seems to be the logical boundary for an object based on factors of complexity and cost. Inputs and outputs could be grouped to create a mantrap or turnstile controller, or a complex set of alarm and output functions. These functions are basically that of a programmable logic controller or PLC.

1. Readers
2. Inputs
3. Outputs
4. Keypads
5. Timers
6. Default times
7. Logic design
8. Simple English operational description
9. Name (renamable)

Benefits of Door Objects

There will be cost savings to the ACS manufacturer, the installing contractor, and the end user. This is a no-lose situation. The volume of software sold by large access control manufacturers is small compared to large software companies. Obviously, it is the unique functionality of Access Control Systems that allows the prices to be what they are. The ultimate cost to the manufacturer for a more flexible system would be less, based on the lack of needing to respond to the many requests for microcode fixes. The entire chain of manufacturer, installer, and user will benefit.

The time required to solve a problem will be significantly reduced. From several large manufacturers, the delay for changes in microcode has been, in some cases, greater than a year. Temporary work-arounds have been used. But, this type of delay is not comfortable for any of the parties. In other cases, the delays have been only hours or days, depending on the urgency and the profile of the job. Unfortunately, these are awkward criteria for the smaller end user who just wants the system to operate as "advertised." Since each door object is an entity, the legacy of one type of door has no relationship to a new object. The programmer of a new door object can look forward without the responsibility and cost to look back.

Long term flexibility will be greatly enhanced because each SRB will be capable of accomplishing the types of functions that are common in PLCs. It has always been awkward and costly to use PLCs to run revolving doors, mantraps, optical turnstiles, sally ports, various styles of elevator control, and the other special security portals that the industry can dream up. By allowing enough flexibility in the object design limits, each of these could be achieved within the structure of one SRB.

DOOR OBJECTS IN ACCESS CONTROL SYSTEMS