AutomatedBuildings.com Article - Power Over Ethernet for Building Automation Systems Retrofits

February 2013
Article
AutomatedBuildings.com

Innovations in Comfort, Efficiency, and Safety Solutions.
Belimo
(Click Message to Learn More)

Power Over Ethernet for Building Automation Systems Retrofits

We felt a bit foolish given our IT expertise, but immediately changed tracks and stopped requesting 120VAC power outlets, instead submitting a request for 802.3af along with each request for a drop and IP address.

Albert M. Putnam
Vice President
Technology Operations
Cimetrics

Cimetrics has a campus customer site with metering for electricity, steam, chilled water and water (most of WAGES except gas and air).

Most meters of interest have Modbus protocol capability – either Modbus as an easy switch in their interface, or Modbus as an added inexpensive internal board from the manufacturer, or Modbus as a simple external box from the manufacturer or a third party. This possibility of a standard interface is generally a surprise for the customer.

Once Modbus is enabled, the need is to get into some TCP/IP protocol for enterprise aggregation. TCP/IP can be carried over many data-links, but WiFi and Ethernet are certainly the most common and easiest/cheapest with which to connect. Semantically meaningful protocols like BACnet, REST and XML can go from there.

Interfaces direct from Modbus to BACnet/IP and Modbus TCP facilitate the connection to TCP/IP. Boxes like Cimetrics Eplus devices – Cimetrics’ B6030 Modbus Device to BACnet/IP edge device and Cimetrics’ B2000 Modbus MBAP RTU/TCP router can do this. Direct pulse pickup can be done by Cimetrics’ B6070.

Cimetrics Eplus devices are Ethernet TCP/IP converters which need power to run and drive RS485 for Modbus RTU and I/O for pulse. For some commodities like water, the installations are hard to bring electrical outlets to, and even with in-house labor involve an expense of approximately a few hundred dollars. There are also costs in bringing Ethernet, but this compares to some locations (like water and sewer vaults) to which WiFi is impractical to bring. The cost of the actual box placement combined with power and Ethernet installation can become greater than the cost of the box itself.

During the campus install the IT department came to the team at Cimetrics (the IT department were installing Ethernet drops) and said:

What are you doing? Don’t you realize that we have a global roll out of 802.3af for VOIP and security services and power for your meter device ports is sunk cost in existing infrastructure – there for the asking (and helpful to use as forward going justification of that PoE [Power over Ethernet] infrastructure install) . Even if we did not have it, in locations where you deploy your own switches/hubs – why not use (cheap) 802.3af enabled gear to get your power?

We felt a bit foolish given our IT expertise, but immediately changed tracks and stopped requesting 120VAC power outlets, instead submitting a request for 802.3af along with each request for a drop and IP address. Forward going install costs were halved. We were able to do this in part because our devices are low power and fit well within the 13W 802.3af PoE limit. Ongoing tracking and maintenance were improved because the IT plant was also the power provider.

It was such a good arrangement that we instituted a systematic programme to get 802.3af capability for all our small box Eplus products. Sometimes this capability is a simple and flexible 802.3af injector. We can provide integrated 802.3af as well where large installs will have 802.3af as the main method of power.

So overall can 802.3af PoE be applicable to building automation systems, BAS, more generally? Where does power come from in a BAS? Let us go deeper and ask – Where does power for anything come from in a building? A few things do their jobs from gas/oil. Some tiny things are solar powered or use other energy harvesting - like the flows that power a water or gas meter, or human power to open and close doors or throw/push light switches. But most power comes from the local or global grid. That means 120VAC single or three-phase at 60Hz in North America (variations abroad).

Devices are wired into AC or plugged into a receptacle. This power is simply a given. When infrastructure is being built into a building the given nature of AC power means power delivery is “free” to devices… at least in the sense that no one would ever value engineer-away outlets or circuits based on the premise that they are “just not done” in a modern building. The existence of power for any given (building automation) device is a non-issue - at least at build time. The attachment of a 24VAC transformer to a nearby circuit to run a damper is no problem when the AC is being installed and the HVAC duct work is being installed.

Daisy chained RS485 networks can be installed while the building is being built. It is just as easy to run Ethernet devoted to HVAC while the building is being built, BUT that is not, as a matter of course, done (today).

HVAC is one of the first building subsystems which must be working after basic structure and power, and Ethernet is installed after all of these. Ethernet thus cannot be depended upon for any of them. Again in purely technical reality Ethernet could be a primary system (with the use of Power over Ethernet and low power or energy storage end devices) but it is just not done (today).

Concede the argument that Ethernet power has any major use today in new installs. Let us focus on the best way to provide power and network to any retrofitted equipment.

Retrofitted equipment includes appliances, telephones, video surveillance gear, and access gear. Go further and include local workspace lights, heaters, humidifiers, dehumidifiers, thermostats, and so forth.

Figure 1 : 802.3af possible devices

In modern reconfigurable spaces, there are more retrofitted devices than one thinks. Basically this boils down to any plug load, or any very low power device.

Any space which envisions high density of knowledge work of any kind (and almost all work is knowledge work these days) has nearby Ethernet jacks. It is as omnipresent today as lights and AC power outlets are and have been.

There is movement to wireless networks as a way to network retrofitted equipment. Wireless inside a structure (with any metal) has transmission pathway problems. And wireless endpoints will need energy when all is said and done. Wireless is especially compelling outdoors or where the powered devices of interest are truly mobile on a minute to minute basis. But let us put these issues aside except to make the point to let the use case truly drive the solution (not fad/hype), And carefully consider something like WiFi or 3G/4G cell before going off on something more “out there”.

Overall we are at a cross roads in history where concerns with energy and efficiency have brought revolutionary improvements to the

- Energy required by real devices to do meaningful tasks.
Dampers, lights, end-point-computers and displays have moved from 100W minimums to 10W minimums.

- Storage of energy to do these tasks
Batteries get slowly better all the time, as do ultra-capacitors and new storage forms. All are motivated by the needs of energy storage in transportation systems. Transportation is a much more demanding use case (with issues of weight and volume) than the average building automation use case (where the needs are reliability, environmental stability and longevity).

- Networks
Old tried and true technologies are now much more efficient. Much can be done with an RS485 wire and an integrated power feed, or with TCP/IP travelling over Ethernet or WiFi. The network problem has always gone hand in hand with the power problem except – as stated herein – when normal AC power is simply a given.

- Question of old versus new
Green-field installs now have a balanced imperative with the need to upgrade pre-existing systems. The core reason for automation is to reduce waste and improve efficiency – whether in materials, human effort or energy. Reducing the installed base waste is often co-measurable with the opportunity for efficiency in new installs.

Servers and data centers are often well past the upgrade/freshen debate with their upgrade cycles allowing the install of truly leading edge technology at each cycle. But buildings, and almost every other domain, tend to have longer upgrade timescales, and are constrained by having to get the most out of what you have for awhile longer.

So there are the opportunities and imperatives. Let us look at automation systems differently as a set of things which can be examined. They can be examined for ways to get better efficiency through analytics.

Cimetrics has seen sensors/actuators deployed in a wide variety of locations over the years. We have been interested in getting the sensor data back to data bases for storage, aggregation, comparison and analysis. In the other direction getting actuation data back to the endpoints from human or machine decision systems presents its own problems (access, security and such). The following issues arise:

- Physical space for node.
- Power for node.
- Communication access for node.

There is not much one can do about reshaping reality for the space needed for a node to function nor can one seriously change the amount of effort must be made to install said node. Different technologies can be easier or harder of course. And things get smaller so far as a node is concerned (size, cost, mass). But one runs almost universally against the issue of power/energy for nodes. For power you can either:

- Bring it with you (battery or fuel cell or fuel generator) – good until source is expended.
- Harvest energy from environment. (solar, thermal, flow-scavenging generators, bio harvesters – essentially living off the landscape).. has potential to run forever – or at least until local breakdown
- Get it from grid (or distribution system)… has potential for forever as well but is rife with external uncertainties and costs. If there is ready a 120VAC or 12VDC outlet/source next to your application – then it is foolish not to use it.

Figure 2: Where to get power

Things change and break, and we have to go visit nodes at least every few years anyway (if nothing else the seasons of a year bring different conditions which are often not intrinsically handled/forethought and cause system stresses). Batteries often have a winning edge if not too much power is required all at once. Energy densities in batteries (and analogs) are a tricky thing. Not enough means dead weight/space. Too much is a hazard. Nodes have gotten more efficient in ways that make batteries more worthwhile even without orders of magnitude (dangerous) energy density increases.

The efficiency (and stability) of nodes has opened a new vector and that is a return to harvesting. But harvesting – apart from solar, or along lines that we do not even think of as harvesting, like flow running a water or gas meter mechanism - is in its infancy.

Harvesting often still only provides very small mounts of power. An ocean temperature monitoring node/mote, harvesting energy from waves, might have a very good chance at operating and even chirping its RF signal every few hours.

So the argument appears logical and settled... If no grid – battery and harvest.

But have we missed something in this carefully crafted pathway?

We need communication. Often one goes to wireless communication for ease of deployment after all else has been considered (including power and space). What if the power comes from the communications? RF harvesting is still in its infancy. What if you invert the order of consideration and start from the premise of running a communication wire to the node? Does that change the energy supply consideration?

A communication network needs power for its intermediary nodes even for wireless. And again these can be provided by battery, harvesting and grid. Battery and harvesting are particularly germane to wireless mesh network systems where peer nodes act as communication relays. But mesh has proven to have issues too. Mesh issues are not insurmountable – but there is not proper consensus (or more importantly alignment of all use cases) to make a universal mesh architecture work.

Wired networks are much better understood and much more stable. Their fixed nature is intrinsic (a drawback for nodes in mobile environments). And they work well with fixed power from grid.

What is a good way to combine a fixed wired network and power? RS485 networks have been installed with one or two spare wires to run AC/DC at low power (say under 20W) to low power target devices like thermostats, small actuators or sensors.

Power line, phone line and CATV line advanced networks have integrated power elements. The advanced forms have limited existing deploy and are thus expensive. CATV line networks are in fact being displaced by PoE 802.3af. What kind of network can supply power? We are drawn to Ethernet 802.3af PoE.

Figure 3: Power over Ethernet 802.3af.

Summarizing the 802.3af basics:

-One can get 10-15W in the most basic case of 802.3af.

-Isolation is standard (inherent in Ethernet) to protect one from spurious ground and potentials. Blow outs from phase crossed 24VAC devices attached to some common I/O point(s) are abated.

-Central and distributed administration of both network and power is usually present. Out-of-the box a managed 802.3af sourcing switch can not only manage VLANs but also the PoE power can be turned on and off by commands issued over TCP/IP.

-Internationalization is a given – no power supply by region - 802.3af is world wide. You can use a PoE power source of your choice for your local region.

All the benefits of Ethernet in its cables, wiring, isolation, termination and general availability in the marketplace are obtained… too numerous to go into at length.

In summary, think about the possibilities of 802.3af. Think about applications where communications are key, and where power can come along for the ride. Think about new low power automation applications which can fit within the 802.3af profile.

About the Author

Albert Putnam is responsible for Cimetrics’ BACnet router and gateway product lines and the automation systems integration group. He manages a team of engineers, technicians, and subcontractors working in support of systems integration. Putnam has extensive experience in network systems development and information collection and conversion. He has background in physics, mathematics, modeling and analysis, and practical experience in cryogenic engineering, microwave technology, and computer electronics. Putnam has had extensive engagement in project and product development. He has managed small teams doing engineering work on various projects since 1985. Since joining Cimetrics in 1997, he has managed a team of engineers in Kazan, Russia, doing both hardware and software embedded systems engineering. He was president of the Canadian Association at Cornell in 1995 and an Autodesk liaison at Cornell from 1994 to 1997. Putnam graduated with distinction from Dalhousie University in Nova Scotia in 1988 and pursued graduate degrees in Physics at Cornell University. His Ph.D. dissertation topic was "Magneto-Dynamic Properties of Dilute Solutions of 3He in 4He at Low Temperatures in High Magnetic Fields.” Putnam is a member of the American Physical Society and the Association of Energy Engineers.

References:

[WAGES] http://www.powerlogic.com/service.cfm/c_id/3/s_id/21
[Modbus] http://en.wikipedia.org/wiki/Modbus

[BACnet]
http://en.wikipedia.org/wiki/BACnet
http://www.bacnet.org/

[REST] http://en.wikipedia.org/wiki/Representational_state_transfer

[B6030]
http://www.cimetrics.com/index.php/b6030-bacnet-interface-to-energy-meters.html

[B2000]
http://www.cimetrics.com/index.php/b2000-modbus-tcp-rtu-router.html

[B6070]
http://www.cimetrics.com/index.php/b6070-bacnet-interface-to-pulse-meters.html

[RS485] http://en.wikipedia.org/wiki/RS-485

[802.3af] PoE Power over Ethernet.
http://en.wikipedia.org/wiki/Power_over_Ethernet
http://www.poweroverethernet.com/

[VOIP] http://en.wikipedia.org/wiki/Voice_over_IP

[BAS] Building Automation Systems
http://en.wikipedia.org/wiki/Building_automation

[HVAC] http://en.wikipedia.org/wiki/HVAC