Introduction

The S4 Group’s initial products integrated legacy building automation systems and published them to open protocols such as OPC and BACnet. Therefore, we have been following the discussion on automated buildings about Open Systems with great interest. We look at our products as being the enablers of open environments. This experience leads us to the belief that Open should not only refer to the implementation of technology but to the philosophy driving the way that a company conducts its business. That is you not only need to talk the talk but you need to walk the walk to offer a truly open system.

This article shares our experiences in developing a derivative product of the original product offerings. In this instance, we developed an integration that provides interoperability between two Open and state of the art environments, BACnet and EnOcean®. Both environments are open; both have very strong industry organizations behind them; both have a very loyal following of developers. With all this going for them, they still cannot talk to each other. So, is either one truly open? The answer is yes, but each within their own segment of the industry.

Before moving forward with the development effort we confirmed that the building automation industry, respective trade associations, and relevant standards organizations have accepted both BACnet and EnOcean® technologies as mainstream offerings. We will not attempt to provide a tutorial on, nor an evaluation of, either technology, or the associated standards.

BACnet International Wireless Working Group Activities

Our Group participated in discussions between the EnOcean® Alliance and the BACnet Wireless Working Group exploring how the EnOcean® technology could become a part of the BACnet standard. The most basic things that became obvious within the Wireless Working Group were that we were not just talking about bringing a protocol variation, or another network transport option, into BACnet, but we had to consider how the entire EnOcean® building automation system technology fit under the BACnet umbrella. EnOcean® devices implemented various traditional HVAC control, access control, and lighting control algorithms and communicated wirelessly to their inputs and outputs, and to each other, via a method that EnOcean® refers to as telegrams. It was simply not practical to force the EnOcean® telegrams (very short bursts of wireless transmissions powered by energy harvesting devices) to follow the BACnet standards. The EnOcean® controllers, sensors, actuators, and the underlying wireless protocol were inseparable. Conversely, the feature rich, and verbose BACnet application layer constructs would not fit within an EnOcean® telegram. In addition, the intrinsic characteristic of powering EnOcean® devices only when needed did not fit well into the BACnet way of implementing “always on” systems. The bottom line is that the EnOcean® standard and the BACnet Standard are two very different approaches to building automation that complement each other.

Even given the above facts, everyone involved recognized the value delivered by the EnOcean® technology, that it held an important place in the industry, and determined that we should instead pursue a gateway approach whereby the power of both BACnet and EnOcean® technologies would be available to the building automation industry in a standards base way. This moved the discussions to how to provide an effective gateway between the two technologies. With this approach, it is up to the gateway developer to:

1. Guarantee that the BACnet side of the gateway follows the BACnet standard
2. Guarantee that the EnOcean® side of the gateway adheres to all EnOcean® Alliance requirements.
3. Provide a reliable and robust implementation of the code necessary to have the two environments co-exist and cooperate with each other.

At this point the discussions about the EnOcean® technology moved from the Wireless Working Group to the Testing and Interoperability Working Group, which was already actively working on proposed addendum 135-2010al defining gateway profiles, and documenting best practices for gateway developers. A working draft of this addendum will be going out for a second public review in the coming months.

[an error occurred while processing this directive] BACnet Interoperability

BACnet is a manufacturer-independent data communication protocol for Building Automation and Control Networks. Developed under the auspices of the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE), BACnet is an American national standard, a European standard, a national standard in more than 30 countries, and an ISO global standard. The protocol is supported and maintained by ASHRAE Standing Standard Project Committee 135 (aka the BACnet Committee).

BACnet increases the probability of interoperability between devices of different manufacturers if all participants in a project agree on certain BACnet interoperability building blocks (BIBBs) defined by the standard. A BIBB defines the services and data that have to be supported at the server and client end to implement a particular system requirement. The protocol implementation conformance statement (PICS) accompanying a device lists all supported BIBBs, object types, character sets and options in communication.

EnOcean Interoperability

The EnOcean Alliance is a consortium of companies working together to further develop and promote self-powered wireless monitoring and control systems for sustainable buildings by formalizing and opening the interoperable wireless standard. The EnOcean Alliance has developed the specification for the interoperability of the sensor profiles for the wireless products operating in license free frequency bands and is in the process of being ratified as an international standard at the IEC technical committee JTC 1/SC 25/WG 1. The EnOcean Alliance is open to anyone and is a manufacturer-independent nonprofit organization based in San Ramon, CA.

The EnOcean radio protocol (ERP) is optimized to transmit information with utmost reliability using extremely little power while ensuring that the products of customers applying EnOcean technology are compatible with each other. Only the very shortest transmission period (< 1ms) for an EnOcean telegram allows the design of, for example, a battery-free radio switch, which can produce a full radio command with just approx. 50 μWs (50 μJ) of energy. At the same time, the reliability of the system increases, as the possibility of data collision is strongly reduced. Every data bit in the radio telegram is essential. For each ‘0’ or ‘1’ state, content descriptions are defined, which the sender and the receiver must follow likewise. Depending on the telegram type and the function of the device, the user data (payload) is defined in EEP (EnOcean Equipment Profiles). The ERP specification defines the structure of the entire radio telegram. The user data embedded in this structure is defined by the EEP.

The BACnet-EnOcean® Router

The following diagram depicts the relationships between the different components of a BACnet to EnOcean® Gateway.

These concepts apply equally to a gateway between any two, or more, well-defined technologies.

• The BACnet Connector portion of the gateway follows all aspects of the gateway Profile defined in proposed addendum 135-2010al of the BACnet standard for the BIBBs supported and defined in the associated PICS document.
• The EnOcean® Connector follows all aspects of the EnOcean standard. In our earlier products this was the proprietary Johnson Controls Metasys® N2 specification. The proposed BACnet standard defers to the developer to achieve necessary certifications or conformance testing for this system.
• The Gateway Engine implementation deals with the details necessary to make the two connectors work with each other. This includes  facilitating referential integrity, data integrity, services, priorities, timing, and any other functions necessary to guarantee the bi-directional interoperability at all levels between the connected systems. Depending on the characteristics of each of the connected systems, this may mean translation and reliable routing of objects. The Gateway engine needs to emulate any objects that do not have equivalents in each connected system. In some cases caching algorithms may be required to accommodate systems that are not “always on”. Under exceptional conditions, appropriate error indications are required in response to invalid or unsupported operations when a communicating BACnet system issues a confirmed request.

[an error occurred while processing this directive] Results

BACnet is ubiquitous throughout the HVAC industry. However, the fact of the matter is that it is not the only viable standard serving the industry.

The introduction of proposed addendum 135-2010al recognizes the existence of, and importance of, non-BACnet systems and networks to the BAS industry. This implicitly embraces both the differences and the power inherent in disparate systems and The S4 Group supports and recommends its adoption.

It is critical that the gateway successfully implements bi-directional interoperability between BACnet and the protocol or system integrated by the gateway. A description of the non-BACnet system is included in the PICS guidelines included in proposed addendum 135-2010al. Digging into this level of detail is not for the faint of heart. On the other hand, the BACnet committee should not have to certify that the non-BACnet components of a gateway product conform to the applicable non-BACnet standards so most of the burden of proof must lie with the developer. That is exactly the approach that we took with this product and why S4 has invested in an extensive interoperability test lab and reaches out to other manufactures in to BAS, and related industries to work together to mutually support integrators and building owners using our products.

Implementing System Level Gateways such as the S4 Open: BACnet-EnOcean® Gateway in a uniform and managed manner guarantees the integrity of all interconnected systems and delivers value to building owners and operators.

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

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