Despite the enormous amount of technological innovation that has occurred during the past 20 years, and the abundance of new technologies now available, there are surprisingly few security systems on the market that actually meet the needs of customers. Unfortunately, many customers discover this only after they have purchased and installed an inadequate system. At that point it's too late, because they've already made a substantial investment in hardware, software, labor, and training. Too often, customers are drawn in by what they see in a product demonstration, without understanding or focusing on the system's underlying architecture or design. The system looks good on a superficial level. Quite often a small system is installed and seems to perform well initially. But as the customer's needs change and the system grows, greater stresses are placed on the system. It is then that hidden design flaws and limitations become much more apparent.
This article identifies the often-overlooked requirements for designing a modern security management system, and discusses the advantages of a software-centered design philosophy over a hardware-centered one.
Distributed Network Design and the Role of the Access Controller
In contrast to traditional centralized network architecture, distributed network architecture means that every intelligent hardware component of the system is designed as a network plug-in compatible module with its own processing and decision making capabilities. The access panel (access controller) is the fundamental piece of hardware in a security management system. In a true distributed network environment, all decisions are made at the access controller rather than at the host computer. Ironically, most security systems currently on the market do not satisfy this fundamental requirement and, therefore, don't have distributed network architecture. Furthermore, vendors of such systems position the fact that their controller must communicate with the host for decision making as an advantage or a significant feature, when in fact it is a major design weakness.
In a well-designed security management system, the access controller is a self-contained, intelligent device, with its own local processing power and sufficient capacity to store a full database of cardholder and other information required to make real-time access decisions. Unfortunately, most access controllers in use today have limitations in physical memory that preclude them from storing a complete ID card database. For this reason, when an access decision needs to be made and the unique ID card is not found in the controller's database, the controller in most systems must communicate upstream with the central host computer (in well-designed systems, with one of the communication servers, which in turn communicates with the central host computer) in order to get the information needed to make the critical Access Granted or Denied decision. This can mean a major delay, because the host computer might be already very busy handling other transactions. If the communication path is through many different network segments, the delay can be even longer. Furthermore, if the network is down, the controller can't communicate with the host at all, and the controller continues to wait for a response. People with legitimate access rights are rejected, and cannot get access to the facility.
The controller is the most reliable piece of hardware in a security management system, with a dedicated communication channel to its downstream devices (readers, alarm input and output points). There are potentially a very large number of downstream events generated in a system. If communication between the controller and the upstream devices is unavailable, the controller needs to be able to store all the downstream events received without losing or overwriting them, until communication has been restored.
The controller must be intelligent enough not only to store such information, but to prioritize it as well. For example, events generated at certain critical alarm points might be of an extremely high priority, and would have to be transmitted to the host computer and displayed in the central station monitoring facility ahead of other alarms and events.
Host-Controller Communications
When the host computer communicates with the controller, it can send information either in single data record transaction or in a block of data as a single transaction. A well-designed communication protocol between the controller and the host system uses asynchronous, full-duplex communication, and sends and receives data to/from the controller in large data blocks optimized for network packet size. Using an asynchronous, full-duplex protocol, the host and controller can exchange blocks of data simultaneously without waiting for each other's responses. In reality, most current systems are using old protocols that utilize synchronous, half-duplex, single data record transaction. This method of communication, even over a very fast network, is really inefficient and becomes a performance bottleneck. Consider this analogy: you might be driving on a highway that has no speed limit, but if you're driving an old jalopy, you can't take full advantage of the highway's speed potential.
Hardware-based Design Philosophy
Most security management system vendors were for many years involved in the manufacture of their own hardware. Along the way, they developed a culture in which their system design continued to emphasize hardware functionality and features. Those companies viewed software as a necessary evil, something they had to provide -- for a nominal fee -- in addition to the "box." This mentality was appropriate years ago, when systems were fairly simple and non-integrated. But modern systems are much more complex. They are more likely to be sold as either "integration-ready" or integrated solutions, incorporating access control, credential management, visitor management, digital video, biometrics, smart cards, and other diverse functionality. As demand for these integrated solutions has increased exponentially, the old hardware-based philosophy has hindered the ability of such systems to scale upward, integrate other components, and perform as the systems grow and become more complex.
Access controllers are typically embedded systems, and embedded systems have a number of serious limitations. To begin with, they have either homegrown or highly specialized, embedded operating systems and limited physical memory. They have no database engine by the classical definition, so data organization and management is very primitive. As a consequence, inserting and deleting/replacing cardholder information is a fairly slow process, particularly when there is a large amount of data. Consequently, scalability and performance are greatly diminished, because as the system grows there is a large amount of information to manage, largely because of the very dynamic nature of data in security systems. Therefore, it might not be the network that limits system performance, but the firmware in the controller itself. Sometimes vendors overemphasize a need for high-speed communication with the controller, while ignoring the fact that there is still an inherent storage management limitation in embedded systems firmware, which is the real cause of the bottleneck.
It's the Software, Stupid!
The basic functionality of an access control system is very simple. On a fundamental hardware level, all systems pretty much do the same thing. They have one central host computer (one or many communication servers), one or many access controllers, and many downstream devices with hundreds or even thousands of input and output alarm points. The host computer stores information for system administration, and downloads device configurations, cards, etc. The controller makes access decisions, and uploads event information from the downstream readers and alarm points for monitoring of alarms and events. This basic functionality of hardware/firmware is the same for every manufacturer, and there is very little room for innovation or breakthroughs in new development. For this reason, a number of forward-thinking companies today have outsourced the manufacture of their controllers. What differentiates these controllers? The application software each uses.
Because of the inherent limitations of the controller's firmware, the real innovation in a security management system must come from the application software. The application software is the glue that holds a complex system together and makes it work. This has been true in all other realms of computing and electronics. Once a hardware technology is in place, it's the application of that technology, through software, that realizes the potential and delivers the benefits. Companies that continue to preach the importance of a hardware-based system design are falling farther behind the norm.
Compare the complexity of firmware on the controller level with the application software, which is on the system integration level. A controller typically contains less than 256 kbytes of firmware code, while a well-written integrated solution contains easily in excess of 256 Mbytes of software code. That's 1000 times more software code than firmware code. This is not surprising, since the application software is really the "brain" of the system. The application software must interact with many more resources and technologies than does the firmware.
Well-written application software is designed using modern object-oriented technology. That means that many lines of repetitive code are replaced with a reusable software object, which becomes the building block of application. Programs are smaller in size due to reusability of objects. Well-written application also uses off the shelf libraries of standard objects and the latest technologies and tools available.
Open Architecture and Seamless Integration
Open architecture is one of the most important requirements in designing a system that works for the customer. Surprisingly, even though open systems a few years ago won the war, so to speak, many vendors still pay lip service as far as open architecture is concerned. Their products are still based on closed, proprietary architecture. In other words, everyone's talking about open architecture, but most security management systems still don't have it.
Just what is open architecture? Open architecture implies that every major software and hardware component of the system, every communication protocol, and every interface is designed according to industry standards that allow easy integration with other systems and components. A well-designed security management system is based on an open design that relies on current de facto industry standards in software design, operating systems, networking, and databases for seamless integration with the corporate infrastructure. In terms of software, the system must support multiple database standards, such as SQL Server, Oracle, and DB2. It must support multiple protocols, such as TCP/IP for network communication, XML for data exchange between different applications, SSL for secure communication, and LDAP for interfacing to directories and directory services.
The system should also provide a standard way of integrating with the outside world -- with other systems and devices. For example, the system must provide standard application programming interfaces (APIs) for ease of integration with different devices such as access control panels, digital video recorders, IP cameras, fire panels, intrusion controllers, intercoms, etc. Customers don't want a jumble of proprietary systems that don't work together. They want integrated, total security solutions that serve their best interests. They don't want to be limited in the third party products they can use. At the same time, they want to preserve their investment in installed field hardware.
Customers have enjoyed the benefits of open systems in the computing environment for years. They want their security management systems to also be designed around accepted technology standards, so that they won't become legacy systems.
About the author: Rudy D. Prokupets is chief technology officer and executive vice president of research and development at Lenel Systems International, Inc. He holds an MS in Electrical Engineering from the Electrical Engineering Institute of St. Petersburg, and a Master's degree in Applied Mathematics from the University of St. Petersburg, both in Russia. In 1985, Prokupets cofounded Edicon, an ID and security management company, and served as its vice president of R & D Engineering. In 1990, Prokupets cofounded Lenel Systems International, where he currently defines strategic directions and oversees all company research and development.
