ZEB - Zero Energy Buildings explained

All the ideas in Zero Energy buildings have been around in some form for a while. The problem is the key elements, such as demand-response, have been centrally controlled. Sign up for this program months in advance, and then the Power Company controls your [water heater]. But what if I want to stay home today? Too bad. Consumers do not want loss of control. This limits participation.

New initiatives are getting closer to changing this. There are now a couple web services protocols for building controls: oBIX and WS-Devices. The newest Windows now is able to discover such services automatically. Soon there will be software to let your PC discover and operate building systems much as they discover printers today. It is not hard to imagine an agent talking to the power spot market, talking down to the systems, reading the electric meter live…

Some of the so-called “Zero Energy” initiatives envision each building supported by multiple on-site energy collection and generation systems. Based upon the building’s operating posture, and the mix of energy sources available, such a building would pull 35% or less of its total energy budget from the grid. If the facility includes local buffering and storage of electrical energy, whether this buffering is in the form of souped-up traditional batteries or new-fangled hydrogen storage, this become viable.

Power comes over the grid as Alternating Current (AC). Power is stored in batteries as Direct Current (DC). Power from the grid must be converted from AC to DC for storage. Before it is used in your home of office, it must be converted back to DC. Power is lost with each conversion. Power from most on-site generation is DC. On-site DC power generation can be stored in those batteries without the losses you expect converting from the AC grid to DC.

If future houses support DC distribution for internal use, then the batteries can become the primary source for the house. Because this removes the loss from converting the DC battery to AC, this effectively increases power stored in the battery with no new storage technology required. Most devices in modern houses are DC anyway. Those little bricks and wall-warts, the rectangular boxes attached to the plug or in the middle of some power cords convert power from AC to DC. This conversion is very inefficient; a third of the power may be converted to heat before it goes any further. The Galvin Power Initiative (www.galvinpower.org) is a good source for the engineering behind this. With appropriate local buffering (batteries), an awful lot of power consumption can be shifted to off hours without loss of occupant autonomy.

Zero Energy Buildings, then, are engineered to be efficient, make some of their power on-site, and shift energy use to when it is cheaper and more plentiful.

Next – Zero Energy Buildings and Shifting Power Consumption

EBMS – Design Decisions for the UNC Enterprise Building Management System

This post continues a series about a particular large system at UNC

As described in the last post, Building System protocols suffer from a number of problems. They are unstable. The protocols are not standards compliant. They have poor security characteristics. So we decided to put them in a sandbox.

Each buildings system was to be isolated within that building. No protocols not easily recognized by Network Support Technicians would be allowed on the backbone; BACnet, LON, et al., were all gone, even their IP versions. All network traffic for control systems would come from protocol stacks that were written for mainstream use. Systems would be secured using our standard network security

All connections to building systems be sessionless. This one needs some explanation. When a program on your computer connects to a database, you log in, and establish a session. That connection is maintained by regular hand shaking. The remote server remembers things about you, so you can continue the conversation. This is efficient, but it does not scale well.

When you contact a web server, you connect, get your page, and then the web server forgets all about you. This allows one web server to service thousands of clients. The standard for sessionless program to program communications is web services. You use web services whenever Gmail types ahead to finish an address for you. We opted to use web services for all routine communication.

We defined two ways to connect to the sand box. It was necessary that we choose names that were not tied to any particular brand, so we made up our own. All communications between the EBMS and the control system are through the Enterprise Building Local Gateway (EBLG). All maintenance of the building system is through the Local Control Station (LCS). Both access points are secured by network security.

We defined a Local Control Station (LCS) to support the needs of each individual system. The LCS runs all the proprietary software that is used to configure the control system. All of them run Windows XP and are members of a windows domain. Users do not have administrative rights on an LCS. All access to LCS’s would be defined by security policy.

The Enterprise Building Local Gateway (EBLG) was created as the gateway and translator. All operational access to the building system is through the EBLG and is exclusively by web services. Maintenance or reconfiguration is performed on the LCS instead.

The Enterprise Building Management System (EBMS) was conceived of as a central harvester of all information from all the web services on all the EBLGs. No software or hardware to work with traditional control protocols would be installed on the EBMS. No traditional controls enter or leave the EBMS.

Using web servers to access the information on the EBMS, operators can see everything in all systems, no matter what the brand or the protocol. This provides a web based point for operating all the buildings. We carefully defined a distinction between Operations and Maintenance/Configuration. You can think of it as the difference between driving a car and performing service on a car.

EBMS – Why we built the UNC Enterprise Building Management System

This article begins a series of articles about a particular large system at UNC

We had a big problem at UNC. Our energy management control room was filled with different so-called enterprise systems. Our buildings were filled with every sort of low bid system that could be purchased under state rules. Where we had been able to impose a standard, internal incompatibilities, between systems from twenty years ago and from ten years ago supplied by the same vendor were as bad as those between product lines. The men in the control room were running a half dozen different incompatible monitoring systems, and all of them were fraught with problems.

As we built out the campus network, it was no longer acceptable to isolate the building systems onto separate webs of leased phone lines. As we moved the systems onto standard networks, the problems became worse. The first attempts by the building systems vendors worked only ion fully isolated networks. Many systems implemented quirky variants of TCP/IP that operated only with certain brands of router. No two chose the same brand of router, and none chose the brand of router selected by out enterprise networking group. With clever trickery, and great expense in time and labor, we were able to work around these problems.

It was surprising how badly the control protocols were written. Developed in isolated labs, by engineers who understood little about the challenges of sharing a network with unknown others, they were really quite bad. Not only were all aspects of these installation discoverable, but they were sensitive. I know one campus whose coal plant control system was taken off line each time an un-configured LaserJet was put on the campus network.

Enterprise control protocols of the day relied on security through obscurity. Anyone who could read BACnet, or LON could discover and operate the entire network. Proprietary protocols such as Metasys or Ultavist were no better. So again, through hard work, and no small expense in network equipment, and even greater expense in time and labor, we put in a complex network of VLANS operating inside the diverse business VLANS of the were able to work around these problems.

The real problems were much worse than I am letting on. Some systems would stop communicating if a router were switched out – until each system in the subnet and neighboring subnets had been simultaneously cold booted. Network stacks written by controls systems houses were abominable and there network interface cards were expensive. I remember tuning network ports down to 10MHz half duplex, to support a $1000 dollar Ethernet interface, while I was buying 100MHz full duplex network cards for $19.

With all the work, with all the effort, with all the off balance sheet costs, I knew the game had to change.

Something’s Gotta Give

Changing business models is hard work. All the new approaches discussed in this BLOG seem not quite justifiable today. They would offer great benefits if they were already set up, but the change, to many, doesn’t make sense. History, and the installed base of markets and technologies, seems to block change.

I work from the precept that long term historical trends do not easily change. The things that drive decision makers will not change. Economic principles are as certain as gravity. We must find solutions to the problems of Energy and Sustainability that acknowledge the reality around us.

I make three assumptions about energy, the use of energy, and the need to deliver energy.

Energy Use per person has been increasing through all of history. It will continue to increase. The number of people using energy will increase. This means that the end-user demand for energy will increase.

Legacy energy sources will get scarcer. The difficulties associated with siting traditional energy generation will increase. The costs of remediating energy siting will increase. This means that the costs of central generation of energy will increase.

Utilities will be unable to build sufficient transmission capability for the needs of the future using current technologies. (Transmission refers to the long distance, high voltage tall towers you see bringing electricity to the fenced-in gray objects at the edge of a neighborhood. From the fenced in area to your house is referred to as Distribution.) Siting new transmission corridors is getting tougher and the lead times longer. One reason that the grid is fragile is that Utilities have been unable to afford adequate transmission expansion; they will be less able to afford it in the future. Increasing energy use will make demands on an infrastructure that cannot keep up with the growth will lead to decreasing reliability.

These three trends, increasing demand, higher cost of generation, and decreasing reliability or transmission, will shake end users, whether in homes, offices, or factories, out of their complacence about current energy provision. This will create the market conditions for technologies and approaches that seem “too risky” today. The risk of standing pat will be seen as larger than the risk of innovation.

I believe innovation will include building systems responsive to enterprise needs and current pricing. I believe innovation will include on-site generation and storage. I believe this innovation will require approaches that accept the heterogeneity of systems legacy and new, of generation systems appropriate to each site, and of storage appropriate for the needs of each business and home. To accomplish this, the underlying processes of each system need to be exposed as discoverable services to agents that are responsible to the owner or tenant for running the building.

Any other approach will take too much customization to ever really grow into a market. Anything that does not grow into a market will leave the needs unmet.