The role of standards in open systems

Apr 1, 1999 12:00 PM, TINA D'AVERSA-WILLIAMS

Open architecture and standards for security systems are necessary for the electronic security industry to progress. But don't confuse "open" and "standards." Single-source manufacturers can provide paths to systems integration without standardization.

The debate rages when you ask end-users, hardware manufacturers, software developers and systems integrators to provide a definition of open systems or for an opinion on the need for standardization in security systems. You get many different responses.

But all agree that some level of standardization and open communication is necessary.

Hardware manufacturers Currently, technology in the security industry is moving too fast for true standards, says Rob Zivney, Hirsch Electronics vice president of marketing.

Also, says Zivney, there is no trade organization or dominant supplier such as Microsoft in the PC industry to push standardization.

Openness only goes as far as the manufacturers' willingness to supply access to protocols, he says.

Frank Gastoni, Mercury Security president, says standards may not be feasible or even necessary.

Openness can be attained if the communication and functional (operational) characteristics are defined and available to anyone wishing to use any of the components, he says. However, he adds, "There is no such standard in the security industry, nor do I know of a viable effort under way to develop and maintain such a standard."

Software developers Suppliers say a software protocol standard is necessary in the electronic security industry. Examples from other industries include BACnet and Lonworks in the HVAC industry and ISA or Microsoft in the PC industry, but the features of a typical access control system go far beyond the simple control and status reporting model required by the HVAC and building management industry.

Microsoft standardized software is a step in the right direction. Scott Sieracki, president of Open Options Inc., has built his company around the belief that open architecture access control and security management systems are here to stay. His philosophy originates from the idea that the access control and security systems' processor should be as common or standard in the overall system as they are in access control cards and readers. Open Options allows the security professional to choose a security system processor technology that is common to multiple security management systems software.

Orion Automation president Greg Danahy says there is already a fair amount of standardization at the hardware level. For example, video cameras from one manufacturer work on another manufacturer's switcher, he says. "Card readers are standardized to a degree. If any reader could work with any access control panel, it would make the system integrator's job easier, but I don't think a hardware standard is necessary for integration. I think the greater need is to provide integration at the system software level, rather than at the hardware level," he says.

System integrators Bill Gorski, business development director for Siemens Building Technologies, Landis Division, agrees: "There should be 'device' standards that allow customers to use their choice of readers, CCTV multiplexers and other equipment with their control systems. Maybe there should be two types, a common security-level protocol and a high-security encrypted protocol. But beyond the devices, such as field panels, you start getting into higher levels of complexity - the very soul of system architecture, which is the way databases are handled internally to the panel and the management infrastructure layer of a system.

"Open protocols theoretically may allow a degree of freedom and comfort for customers. They can stifle creative problem-solving, however, or at least lengthen development time, because manufacturers have to agree before change can be made to the open protocol. If a protocol goes beyond defining exchange of data and begins to dictate how applications are performed, the problem gets worse. Manufacturers lose the incentive to research and develop improvements because they cannot achieve a substantial payback - they have to give up their innovations to all manufacturers to remain open.

"We are not suggesting there should be no standards," Gorski continues. "We are saying they may be applicable to certain portions of software or hardware, e.g. a standard protocol for information transfer among unlike systems such as HR software, access systems, card readers and panels. Maybe a better concept is to promote a standard of openness on a system platform to simplify development of translations from one system to another.

"With BACnet in the HVAC industry, there is more show than go," says Gorski. "BACnet is a protocol that can be implemented in a variety of ways. For example, three manufacturers could meet a specification for BACnet compatibility, but still not be able to talk to each other or, at the very least, in doing so would degrade total functionality.

"Manufacturers make many claims, but they mislead end-users. In masking the abilities or inabilities of the protocol, manufacturers can create expectations that are unrealistic. End-users could lose capabilities of a particular system because of conformance to a standard or could incur increased cost or complexity of specification."

With BACnet and other open protocols, unless an overall system specification is carefully conceived and responsibilities are clearly defined, the customer could end up with multiple systems conforming to the functionality of the least common denominator.

The concept of BACnet was to protect end-users from being locked into a particular manufacturer. The truth be told, a particular manufacturer's implementation of BACnet could still provide varying functionalities and some degree of proprietary character. So, for example, if a particular manufacturer's implementation of BACnet is used as a model for a specification, the manufacturer could effectively lock-out other manufacturers by making them invest money in conforming.

Standard protocols are useful when they allow integrators to do what the end-user wants. But standard or even open protocols are not necessary for every level of integration. What is required is an open system software platform.

End-users Siemens' end-user clients do not ask specifically for open technologies, says Gorski. They ask for functionality in terms of what they need for their particular business. For instance, users commonly ask to be linked to a database other than the access control systems database so they can save time by eliminating the need to enter information twice. They are requesting that the access system be NT-based so it can be supported by their IS group and in some cases take advantage of an existing in-house local area network (LAN). Most of the LAN requests are for the management layer of communication (PC to PC).

The security industry has the opportunity to observe the struggles - and successes - other industries have had incorporating standards into systems. If the security industry decides a standard is the right direction, an existing standard or a subset of a standard should be used rather than yet another standard.

However, Zivney cautions, "The one thing we give up in opening up systems is a single point ofaccountability. Clients want integration mostly because they have an investment they want to reuse. This doesn't require open systems, only a company willing to support integrated systems. The bottom line is for the customer to have a better system. Integration can be achieved without meeting both definitions of openness."

"System manufacturers need to realize that the customer wants more options than any single manufacturer can offer," says Danahy. "A few manufacturers offer complete integrated systems. They tend to be expensive and usually lock the customer into golden handcuffs. The end-user cannot add new features or bring in other technologies unless the manufacturer supports them. System integrators and end-users want to be able to buy the best products or technologies from various manufacturers, and they want to work together seamlessly. Manufacturers have to get beyond the master/monster mentality and realize they produce part of a system, not the whole system.

"System manufacturers need to agree on what level of integration is desirable. For many years we have heard how integration means unified databases. This type of integration is great for the access control system and the personnel people, but it doesn't meet the needs of the security department. What the security people want in an integrated system is to be able to control the on-line functions of the system, such as opening a door or gate and responding to alarms. The CCTV, alarm, and intercom systems really don't care about cardholder databases. The real need in the industry is to provide a standardized way of exchanging event and control information among subsystems so an operator can control the on-line functions easily and quickly with a common graphical user interface."

Open architecture technologies can be a key enabler to integration across systems, but are not sufficient for a complete solution today. The flexibility to communicate with a variety of systems is necessary, but one can't use open protocols exclusively to accomplish total communication in an industry that has relied on proprietary components. In fact, using only open or standard protocols could limit a system's ability to integrate with the variety of systems and technologies on the market today.

Open architecture and standards are necessary for true integration to occur. The current debate is what level of standardization will develop across the hardware and the software levels. It's a question security professionals will struggle with in the foreseeable future.

Coming in May: Industry Outlook explores the end-users' case for open systems and standardization.

Offering analysis and commentary on the security industry at large, our goal is to keep readers informed of the market growth and forward movement within the industry. The column is written by Access Control & Security Systems Integration publisher Tina D'Aversa-Williams, whose background includes work in market research and analysis.

Want to use this article? Click here for options!
© 2012 Penton Media Inc.

This month in Access Control

• Targeting The Customer
• Electronic Pedigrees
• One Hero Among Many
• Who? What? When? Where? Why?
• More from September's issue