A Brief History of Building-Automation Interoperability
Interoperability and integration are not new subjects. Everything from the width of train tracks to the voltage and frequency of electrical outlets was at one time proprietary. Even the range of pressure per square inch (psi) used by pneumatic control systems became standard prior to the advent of direct-digital control (DDC) systems.
Interoperability and integration are not new subjects. Everything from the width of train tracks to the voltage and frequency of electrical outlets was at one time proprietary. Even the range of pressure per square inch (psi) used by pneumatic control systems became standard prior to the advent of direct-digital control (DDC) systems. Interoperability is merely the current evolution of building automation.
Of course, DDC controls brought forth a myriad of new benefits to building automation, but interoperability was not one of them. Just as pneumatic systems were standardizing on the pressure range of 3 to 15 psi, computerized control systems became popular and introduced many new proprietary methods to perform similar functions. Although each vendor had a different proprietary method of control, the new systems held enough benefits that their attractiveness grew to the point where nearly all new systems installed were DDC.
Not long after DDC became common, building owners began to feel that the manufacturers of these proprietary systems were behaving unfairly. It became commonplace for vendors to lower their prices for the first phases of large projects, and make it up with far larger profits on subsequent additions and maintenance.
During the late 1980s, interest groups and manufacturers began to actively work on methods of interoperability. Several companies published their protocols, proclaiming that if everyone adopted their language, they could all communicate. Others released "tier-2"-lower-level-protocols for their proprietary networks, allowing willing manufacturers to create devices that could exist on the lower end of a proprietary hierarchical system, keeping "tier-1" higher-level protocols for themselves, thereby retaining the control system monopoly.
While some manufacturers were releasing portions of their proprietary protocols, another attempt toward interoperability specifically aimed at heating, ventilation and air-conditioning (HVAC) building automation was emerging. The BACnet committee, or SPC 135P as it was known then, was sponsored by the American Society of Heating, Refrigeration and Air-Conditioning Engineers (ASHRAE)-which had created hundreds of standards in the past-first met in early 1987 to create an interoperable control protocol with a focus on building automation.
The task proved extremely difficult to complete and even more cumbersome to refine. Cooperation would prove to be a difficult commodity to obtain, so to gain consensus, several options and choices were included and other issues, such as product conformance testing, were postponed. In 1995, the 501-page BACnet specification was released to the public.
Today, there are there are four manufacturers making systems that are "native BACnet" and 44 manufacturers that make at least one BACnet product. Of the total manufacturers making product, over 90 percent create gateways to proprietary control devices or systems.
As for recent developments, the BACnet Manufacturers Association (BMA) was formed last year to perform certification and conformance testing and currently boasts 14 members.
LonWorks starts up
As the BACnet committee was struggling with the problem, so was Echelon, a Silicon Valley start-up that had created a control protocol known as LonTalk. To deal with issues of interpretation and product conformance, the company placed an implementation of their new LonTalk language on a low-cost integrated circuit (IC), the "Neuron," and licensed rights to make the chip to several IC makers. The chip and tools used to embed it into products was called "LonWorks," and control-system manufacturers could quickly incorporate LonTalk into products for interoperability. Many did, and the LonTalk protocol eventually became an ANSI standard.
These LonWorks chips were small and cheap enough to be used in even the tiniest devices, rather than providing only the system-level integration that was being envisioned with BACnet. Everything from actuators and occupancy sensors to emergency lights and weather stations quickly began to incorporate LonWorks., Today, some 4,000 manufacturers offer compatible products.
To deal with conformance and testing, Echelon recruited manufacturers making LonTalk devices and in 1994 formed the LonMark Interoperability Association. This nonprofit coalition creates guidelines for interoperable products and tests those products against the guidelines. Testing and certification fees are pooled and used to advertise certification benefits.
LonMark membership includes makers of HVAC controls, sun blinds, elevators, lighting, access, security, fire- and life-safety, networking and process products. Over 300 LonMark-certified products are now available to specifiers.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.