Door Objects for Access Control

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.

Return to Top

1 - 2 - 3 - 4 - 5 - 6 - 7 - 8