A little more than twenty years ago, a group of engineers within ASHRAE set out to design an open protocol for building automation – BACnet. In the intervening time, BACnet has become the ASHRAE, ANSI, and ISO world standard for building automation communication. It is supported by nearly every vendor in the industry and has been deployed on millions of devices.

[an error occurred while processing this directive]

[an error occurred while processing this directive]

Why did BACnet win out over other, potentially competing protocols? Because the designers understood the problem domain well. BACnet defined the right data types, objects, and services for building automation as well as other general pervasive networking and control applications. The BACnet designers also understood the importance of self-description and discovery as an aid to practical field implementation of a control protocol.

But as successful as BACnet has been, some parts of it have not aged as gracefully. When the design of BACnet started, LANs – “Local” Area Networks predominated. Networks did not extend beyond buildings and it was presumed that the network was physically secure. Multiple network protocols – IPX, NetBIOS, TCP/IP, DLC, XNS all co-existed – sometimes within one company. People believed in the OSI seven layer stack. In this environment it was natural to believe the BACnet should be another network protocol, defining pieces of itself at multiple layers within the OSI stack.

Fast forward 20 years and LANs have almost universally been interconnected into WANs.There is only one network protocol that counts – IP (now in v4 and v6 flavors).There are more networks and networked devices than the BACnet designers could have dreamed of. This has brought to the fore serious issues due to BACnet defining its own network layer:

• BACnet does not scale well beyond the building, in an era where remote monitoring and maintenance is increasingly desirable

• BACnet does not have a good security story, beyond physical isolation of the building network, which is increasingly difficult to preserve in a highly networked world

• BACnet’s use of broadcast packets can be problematic in large systems

At the same time, there are new and important applications that require the interconnection of what were formerly discrete islands of control (i.e. buildings or campuses) into wider managed networks:

• Energy efficiency

• Ongoing commissioning

• Enterprise energy management

The pervasive interconnection of formerly disparate control systems is one of the elements necessary for the realization of the today’s rapidly emerging “Smart Grid”.

Virtually all of these issues stem from BACnet having its own network protocol, distinct from what has become the world network standard. The current layering of BACnet on top of IP, although widely used, does not address these deficiencies. A number of industry players have realized that the BACnet network layer needs to be replaced, and the obvious direction is to define a new iteration of the BACnet protocol that adopts IP protocol, not as a datalink that BACnet’s own networking protocol is layered on top of, but rather as a replacement, in its entirety, for the BACnet network layer. A “BACnet IT” protocol would enable the adoption and use of best-practices from the networking industry. This would enable the use of proven IT solutions for the issues of security, authentication, and network management.

Session Overview
Connectivity Workshops
June 8, 2009
1:00 pm - 3:00 pm
Energy Management 2.0

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]