The movement toward open systems and the desire to use third-party products have become driving forces for new product integration in the security marketplace. In many respects, the security industry is just coming of age. Only in the past couple of years have software developers begun to really focus on the growing opportunity of open systems. For years security professionals have purchased systems in a haphazard manner, buying each standalone component from a different supplier.
Each component of a security system was usually installed for a unique reason. Fire systems, mandated by the AHJ and insurance (in the US), were often supplied as part of the building.
Insurance companies encouraged or required the use of a burglar alarm, especially if the facility had already been robbed. CCTV installations, similarly, were pushed through by management when there was a potential loss of company assets. Photo ID may have been mandated by corporate based on risk management policies. And access control was the big daddy of them all, often only installed when the horse had bolted from the stable and there was new, strong pressure to secure the complex from unwanted access.
These systems were often incompatible and left the end user with a highly dysfunctional total system. No standards existed, and data was not exchanged between systems.
Expansion was not deemed a pressing issue, nor was migration to the next generation of equipment.
About a decade ago, a number of the larger equipment manufacturers who make multiple product lines began to produce highly integrated solutions. This resulted in a number of excellent solutions, but all of them were based on a proprietary architecture. The end-user remained limited, because competitors' systems could not be included. The manufacturers' strategy in this was often to protect their own turf.
A common security system protocol
Peter Manolescue, sales and marketing director for SecurityXML Integrated Solutions, wrote a white paper in August 2002 entitled 'A common security system protocol'. In the paper he paints the security industry as a Cinderella, saying that in many cases security is treated like an afterthought or an unnecessary expense for which there is no viable corporate ROI. Manolescue concludes that the eventual solution of open systems integration may come from a totally different area of the marketplace: from any of the number of mainstream software suppliers that are gearing up their product offerings for the security market.
Over the past two or three decades, the mainstream computer world has been bravely pursuing open systems with significant success. The economies of scale and the need to improve efficiency have forced many companies to automate their entire workflow environment.
In the security world, proprietary systems built to accepted and recognised standards appeared to be an acceptable solution for a period of time (mid-1980s to 1990s).
However, rising licence fees, along with moves by the existing software manufacturers to keep any newcomers out, encouraged developers to devise a whole new level of systems that were not so harshly governed. These became the open systems of today.
This move to using commonly available computer hardware and software became easy to justify as proprietary systems became too expensive to write for and maintain. During the 1990s, an open system revolution swept through the IT industry, converting islands of computers connected by proprietary networks into the Internet - the network of networks based on the following openly available standards:
* TCP/IP - Communications.
* SMTP - E-mail.
* HTTP - Display of Web pages.
* XML - Exchange of data.
Open systems are able to communicate with each other and seamlessly transfer information between databases and users. Central to open systems is the use of open protocols - openly published standards to which all software programs must comply.
Many programmers began to write programs that allowed for the easy exchange of information between diverse systems. In the area of facility automation, tremendous progress has been made in the development of systems and methodologies to allow for communication between systems from different manufacturers.
Open protocols in building automation
In BAS/HVAC and lighting in particular, the pressure on manufacturers to make their products talk to each other became a dominant factor in the past decade. Users of these systems began to see the benefits of a networked solution that was operating to recognised standards and that also allowed for adaptability and flexibility.
Two interoperable protocols for building automation systems have emerged over the past decade in the United States: LonWorks and BACnet. The war between these two is by no means over and may never be over. Both protocols have their supporters, and both allow for ease of use.
BACnet was initially developed by ASHRAE (American Society for Heating, Refrigeration and Air-Conditioning Engineers) and is based on a systems-down approach. It consists of a detailed seven-layer methodology for the transfer of information between dissimilar systems. It has gained a lot of support amongst manufacturers, consultants and end users because it allows many older systems to be integrated into newer ones.
LonWorks, on the other hand, places the intelligence on a chip located in each node, thus building the system from the device up. Echelon Corp. developed the communications protocol called LonTalk, and Toshiba and Cypress Semiconductors make the chips. The neat part about LonWorks is that there are some 400 manufacturers who make products that can all communicate with each other. Manufacturers, vendors and end users have set up the LonMark Interoperability Association to administer the program. LonWorks is particularly strong in Europe and Asia, and its popularity in the United States is growing rapidly.
In an article entitled 'Understanding Open Protocols' in Building Operating Management in August 2001, author James Piper recommends a four-step approach to the selection of the correct protocol. The savvy security manager should heed his advice.
Security systems manufacturers did not follow the BAS/HVAC community in their pursuit of open protocols, instead hiding under the cloak of the 'UL standards prevent us from doing so' mantra. In reality, they were afraid of losing their client base and considered this to be a sensible strategy to keep control of their customers.
BACnet and LonWorks have not succeeded to any great extent in integrating with security. BACnet is making some progress appearing as an interface on some fire alarm panels and other alarm panels, but very little else.
IT's influence on security protocols
The convergence of IT and physical security is adding a new emphasis to the area of open systems protocol, in that the more the security department uses the existing network (controlled and funded by IT), the more dependent security will become on the IT system. IT departments generally prefer working with open systems, which allow them easy access to the information they need to do their job effectively. Remote locations can now more easily connect to the network, but the connection is controlled by the IT department, which sets the rules, regulations and standards.
IT departments also generally prefer working with hardware and software that they understand and that can be supported within the existing communications infrastructure. Thus PCs using Intel or AMD CPUs are preferred, and software operating systems like Windows, Linux and Unix are likewise preferred. The only area in which a degree of flexibility is permissible is that of embedded PC field controllers.
In Peter Manolescue's white paper 'A common security system protocol' (August 2002), Manolescue indicates that developments in other areas of the industry have paved the way for other protocols that may well overshadow the BACnet/LonWorks debate. Among these new protocols are the following.
* XML: Extensible mark-up language, or XML, allows software to communicate with other software and will set a new standard for all software communication. Furthermore, it allows for backward and forward code migration.
* OPC: OLE for Process Control brings in the depth and breadth of industrial automation. The use of XML in OPC will result in a whole new specification: OPC-XML.
* UPnP: Universal Plug and Play is already in use in the home automation market and is based on XML. It is used for video, audio, lighting, HVAC and security, and it is now moving into the wireless arena.
* .NET: A relative newcomer, Web Services or .NET has significant backing from Redmond.
According to Manolescue, all the effort being put into XML-based software could bring about an era in which buyers will be free to decide on best of breed for each system element as they can do today with IT hardware.
On a related note, if the Security Industry Association has its way, its Open System Interoperability and Performance Standards (OSIPS) will prevail. OSIPS is currently being presented to the US government and the Department of Homeland Security as a way to get rid of the many different proprietary offerings and replace them with a unified standard protocol, which may or may not be open to all.
Third-party suppliers
Another way in which a number of manufacturers are attempting to overcome the difficulties in providing their customers with an open solution is to embrace third-party suppliers. Manufacturers are reaching out to third parties that have demonstrated an ability to produce reliable, cost-effective sub-systems that can be combined to make up a totally integrated solution.
One company that has been working hard in this area is AMAG. In order to get a more authoritative understanding of the needs of the market, AMAG commissioned a market survey of 320 independent security dealers and consultants in December 2003. Many of the survey's questions dealt with the manner in which security dealers and consultants prefer to go about the integration process. One question in particular went to the heart of the open systems protocol topic, asking respondents if they would prefer access control products that integrated with their own internally-developed enhancements (biometric, DVR, etc) or that integrated with mature third-party products.
More than 77% of the respondents replied that they would prefer to integrate with mature third-party products rather than with in-house product offerings. The responses from security dealers and from consultants were very similar.
The adoption of open systems protocols by an increasing number of manufacturers will allow end-users to move away from proprietary services and products, resulting in more choice, a reduction in built-in obsolescence, an easier path to upgrades and integration into third-party systems.
Lionel Silverman, P.E., a professional engineer registered in Florida and Georgia, has been working in the security and access control field for the past 25 years in both the USA and South Africa. He is vice president of business development for Facility Robotics Inc, a nationwide systems integrator specialising in building automation and security systems for larger multilocation and prestigious clients. Silverman is a member of IEEE and ASIS.
Open Systems Protocol was originally published in Security Technology & Design, March 2004, and is republished by permission.
© Technews Publishing (Pty) Ltd. | All Rights Reserved.
printer friendly version