IPfocus - IP UserGroup

IPfocusview from across the pondOpen Systems ProtocolThe movement toward open systems and the desire to use third-party products havebecome driving forces for new product integration in the security marketplace.In many respects, the security industry is justcoming of age. Only in the past couple ofyears have software developers begun toreally focus on the growing opportunity ofopen systems. For years previously, securityprofessionals purchased systems in ahaphazard manner, buying each stand-alonecomponent from a different supplier.Each component of a security system wasusually installed for a unique reason. Firesystems, mandated by the AHJ and insurance,were often supplied as part of the building.Insurance companies encouraged or requiredthe use of a burglar alarm, especially if thefacility had already been robbed. CCTVinstallations, similarly, were pushed throughby management when there was a potentialloss of company assets. Photo ID may havebeen mandated by corporate based on riskmanagementpolicies. And access control wasthe big daddy of them all, often only installedwhen the horse had bolted from the stableand there was new, strong pressure to securethe complex from unwanted access.These systems were often incompatible andleft the end user with a highly dysfunctionaltotal system. No standards existed, anddata was not exchanged between systems.Expansion was not deemed a pressing issue,nor was migration to the next generationof equipment.About a decade ago, a number of the largerequipment manufacturers who make multipleproduct lines began to produce highlyintegrated solutions. This resulted in a numberof excellent solutions, but all of them werebased on a proprietary architecture. The enduser remained limited, because competitors’systems could not be included. Themanufacturers’ strategy in this was often toprotect their own turf.Peter Manolescue of SecurityXML, wrote awhite paper entitled “A Common SecuritySystem Protocol.” In the paper he paints thesecurity industry as a Cinderella, saying thatin many cases security is treated like anafterthought or an unnecessary expense forwhich there is no viable corporate ROI. Peterconcludes that the eventual solution of opensystems integration may come from a totallydifferent area of the marketplace: from any ofthe number of mainstream software suppliersthat are gearing up their product offerings forthe security market.Over the past two or three decades, themainstream computer world has beenbravely pursuing open systems withsignificant success. The economies of scaleand the need to improve efficiency haveforced many companies to automate theirentire workflow environment.In the security world, proprietary systemsbuilt to accepted and recognised standardsappeared to be an acceptable solution for aperiod of time (mid 1980s to 1990s). However,rising license fees, along with moves by theexisting software manufacturers to keep anynewcomers out, encouraged developers todevise a whole new level of systems that werenot so harshly governed. These became theopen systems of today.This move to using commonly availablecomputer hardware and software became easyto justify as proprietary systems became tooexpensive to write for and maintain. Duringthe 1990s, an open system revolution sweptthrough the IT industry, converting islands ofcomputers connected by proprietary networksinto the Internet—the network of networksbased on the following openly availablestandards:● TCP/IP—Communications● SMTP—E-mail● HTTP—Display of Web pages● XML—Exchange of dataOpen systems are able to communicate witheach other and seamlessly transferinformation between databases and users.Central to open systems is the use of openprotocols—openly published standards towhich all software programs must comply.Many programmers began to write programsthat allowed for the easy exchange ofinformation between diverse systems. In thearea of facility automation, tremendousprogress has been made in the developmentof systems and methodologies to allow forcommunication between systems fromdifferent manufacturers.Open Protocols inBuilding AutomationIn BAS/HVAC and lighting in particular, thepressure on manufacturers to make theirproducts talk to each other became adominant factor in the past decade. Users ofthese systems began to see the benefits of anetworked solution that was operating torecognised standards and that also allowedfor adaptability and flexibility.Two interoperable protocols for buildingautomation systems have emerged over thepast decade in the United States: LonWorksand BACnet. The war between these two is byno means over and may never be over. Bothprotocols have their supporters, and bothallow for ease of use.BACnet was initially developed by ASHRAE(American Society for Heating, Refrigerationand Air-Conditioning Engineers) and is basedon a systems-down approach. It consists of adetailed seven-layer methodology for thetransfer of information between dissimilarsystems. It has gained a lot of supportamongst manufacturers, consultants and endusers because it allows many older systems tobe integrated into newer ones.LonWorks, on the other hand, places theintelligence on a chip located in each node,thus building the system from the device up.Echelon Corp. developed the communicationsprotocol called LonTalk, and Toshiba andCypress Semiconductors make the chips. Theneat part about LonWorks is that there aresome 400 manufacturers who make productsthat can all communicate with each other.36_issue 3