Making New Homes ready for Smart Energy

Smart energy names the techniques and technologies needed to manage energy flows and energy supply and demand when energy generation and energy storage are as distributed as energy consumption is today. Grid assets are managed by central control. This only works so long as the assets are central and the assets are centrally owned. Distributed assets should have distributed ownership. We must turn the centralized model on its head. Smart energy manages from the edges, not from the center. Smart energy treats homes and commercial buildings as microgrids responsible for their own power.

The concern of smart energy policy is to remove barriers to enable rapid entry and virtuous markets for new technologies. Policy is implemented by regulations and codes. Today’s post arises because I am wondering when we will have a model building code for the smart energy-ready residence. What should a commodity builder do if he wishes to claim that each home in a neighborhood is “smart energy ready?”

Let’s start with the interconnect. Today’s rules for distributed energy focus, as they should, on safety first. To this end, they mandate anti-islanding, i.e., if the grid goes away, power systems shut off. This prevents a linesman from being electrocuted when the downstream side of a downed line is “hot.” The model smart energy ready building should instead choose safe islanding. Local power systems, generation, batteries, even electric vehicles, should work safely within the home no matter what the local conditions. Software and hardware at the building entrance should support this safe islanding.

Within the home, there should be an emphasis on safety and extensibility. The Electrician working in a house needs to be just as concerned with unexpected power sources as does the linesman outside the house. If there are distributed energy resources, then there will be unexpected power sources in the home. The interconnect in the house is as important as that between the house and grid.

So we need two interconnects.

Rooftop solar requires paths and connections. If added during construction, conduit to the roof to support the eventual installation of PV costs almost nothing. This conduit can be put in while the walls are open and before siding is installed. Designed-in conduit is less likely to leak then after-thought retrofits. Preparing for roof-top PV likely means planning for an inverter closer to the home’s power distribution panels. 

A similar logic suggests that garages should plan for plug-in electric vehicles, even as the standards for them have not gelled. My guess is that this area will come to be dominated by smart charging stations coupled with storage. Whatever the technology, there will need to be wiring able to safely support high power flows over long periods of time. In the smart energy ready home, empty conduit may be enough for now.

The smart energy ready home should plan for power storage. Chemical based storage systems may lose much of their capabilities at extreme temperatures. There should be some space for storage installation that has an adequate and safe path to and from central power distribution. Again, empty conduit may be adequate for now.

To achieve reliability goals, some homeowners will opt for site-based generation. At its simplest, this requires a pad and conduit back to the central power distribution for the house. At its most complex, it requires very complex configuration. Because utilities today must pay above market rates for solar generated home power, they must watch carefully to make sure that the homeowner is not selling them “solar power” sourced from a backyard gasoline generator.

The answer is to get rid of the above market rates, and let the homeowner operate in the market. Distributed energy resources are first and foremost to serve the needs of the distributed site.

When I consider smart, distributed energy, I always call to mind the words of Doug Gwyn, when asked of a feature in UNIX: “UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things.” We must be careful that we apply the same thinking to distributed energy.

To get more participants in smart energy, we must make it easier. A good start would to be to define the requirements for a smart energy-ready home. We can then see if builders would be willing to build them, and whether the market will bear the trivial costs, or at least trivial if designed in.

Slim BIM: The Middle Ground between Document and Service Part 2

In my last post, introduced Slim BIM and the critical need for shared configuration to speed development in the building systems. This post extends that conversation.

A report from NREL, delivered last Spring, defined the Building Service Interface (BSI), a standard for interacting with building systems from non-building applications. That report recommended that each BSI be able to share a light-weight BIM, i.e., to be able to provide on demand a description of the space it supports, the systems it controls, and the relationship between systems and space. In the future, this light-weight BIM is likely to be part of minimum commissioning standards to get LEED or other environmental certification.

Mary Ann Piette, Staff scientist at Lawrence Berkeley Labs and Director of the Demand Response Research Center, has called these light-weight models “Slim BIM”. Today, there are two well-known specifications for Slim BIM: COBIE and GBXML.

Green Building XML (GBXML) is already well known to the building automation community. GBXML was originally developed to prepare energy models. GBXML has an easily used schema that is maintained by the non-profit Open Green Building XML Schema (gbxml.org). GBXML has become the de facto standard for exchanging information between with engineering analysis tools. GBXML is typically produced by CAD software including applications from Autodesk, Bentley, and Graphisoft. GBXML is used by energy modelers, HVAC design tools, ductwork CAM tools, and many others. GBXML is so well accepted, in part, because its schema is specified using modern tools that are easy for software developers to use.

COBIE, the other Slim BIM, has found a harder path to wide acceptance. Much of the COBIE produced today is of poor quality and semantically incomplete. Within BIM, information is exchanged using the Standard for the Exchange of Product model data (STEP). STEP is able to convey almost any kind of information, including detailed 3 dimensional data. The problem is, most users of this information do now want complete specification and wide extensibility; they need terse, validate-able information exchanges. Most users do not want detailed purpose-built information exchanges developed slowly in committee; they need ready-to-use exchanges that suit a variety of purposes. COBIE’s slow uptake epitomizes the cultural and technical differences between the engineered world and commercial IT.

COBIE would face less cultural resistance if it looked more like other inter-domain information exchanges. Some proponents have claimed that there is a COBIE XML format already. COBIE was initially described as “a spreadsheet of the data you need to operate the building”. Accordingly, standard Excel templates for COBIE are available. Today, the XML representation of COBIE is the XML representation of a Microsoft Office document. As this format is not very useful, most COBIE is produced as hard to understand, hard to verify CSV files or STEP text. The only COBIE verification tool that I know is offered by Onuma Planning Systems (http://www.onuma.com/products/OpsAndCobieValidate.php).

The Army’s Construction Engineering Research Lab (CERL) is a pioneer in using construction information to improve building design, acquisition, and operations. To CERL, improved operations are central to sustaining facilities not only during lean budgets, but also to sustain mission support. CERL’s PROJNET system, used by thousands of organizations, is the leading producer and user of COBIE. PROJNET maintains an internal XML representation of COBIE, one that is not now part of the specification.

When CERL releases its XML representation of COBIE, I predict it will soon become the dominant form for information exchange. A version of COBIE that is as easy to use, and as clear to understand as the GBXML schema will find rapid acceptance throughout operations. CAD vendors that produce poor or incomplete COBIE today will up their game. Current CAD systems require requires a few simple early design decisions to be able to produce good COBIE; designers who skip that step will find themselves at a competitive disadvantage.

Even the mash-up approaches to BIM will benefit. A CMMS that can export well-formed COBIE will be able to export information to Cloud-based BIM. Mash-ups between 3D building models and energy management systems will become common and expected. Well-formed, validate-able COBIE will make building information more visible than it has ever been, visible to the right user, at the right time, with the tools of that user’s choosing.

As these approaches replace the one-time, hard to perform integrations of today, BIM and system integration will become rapid and easy. Cloud-based techniques will reduce the costs of technology changes within each building at the same time as they expand the owner’s awareness of these changes. Shareable configuration is the path to rapid secure service integration.

Slim BIM: The Middle Ground between Document and Service Part 1

Engineering information is document oriented. Large documents, even sheaths of documents, are exchanged, specifying in great detail exactly what to do, and how to do it. Modern IT (Information Technology) is based on Services. Service exchanges are minimal, as small as can specify results, and do not specify the means of execution at all. For the last 50 years, IT has moved far faster than have engineered system, the things we can touch, inhabit, or ride around in. For the next 50 years, when engineered systems will need to evolve as fast as IT has for the last 50, we will need a middle ground, between document and service call. This is the challenge of configuration, shared configuration that will enable big systems to interact as nimbly as does IT does today.

Buildings are big systems, composed of big systems, that must interact with the IT-based systems of their occupants. The systems of the occupants will change many times during the life of a building. If we are to meet national and international energy goals, the collection of systems in each building will change frequently as well. These systems will interact with services, simple calls conveying only requests and results. Before they can communicate with each other as services, each must learn about the other. Each system must be configured with the information it needs to request services. This information must be non-specific, to avoid the complexity of details. This information must be specific, cataloguing service entry points and potential performance.

For buildings, designed by architects and engineers, the design and specification uses BIM (Building Information Model). These are traditionally very large and cumbersome files. The National BIM Specification (NBIMS) describes documents based on the International Foundation Classes (IFCs). The IFCs are two cumbersome for exchange, so NBIMS specifies Information Delivery Models (IDMs) for each structured hand-off of information, and a model view for each IDM. These information exchanges are detailed and overly specific. They rely on document-centric notions of XML from long ago, seen as a “replacement” for large the documents in SGML. The IDM for each stage of a project is different, even if the information is essentially the same.

The problem is, no one outside of architecture and construction uses these approaches, and few seem willing to adopt them.

Recently, members of the National Institute of Building Science (NIBS) have worked on the hand-off of information at the end of a construction project to the maintenance management system (CMMS). They have developed the Construction Operations Building Information Exchange (COBIE). COBIE lists the spaces and their fittings, the systems and the spaces they support, and the equipment in each system with its maintenance requirements and spare parts. The market leaders in CMMS each support COBIE import. Maintenance staffs have reported replacing weeks of error-prone hand entry with 15 minutes of COBIE import, and had their Preventive Maintenance (PM) and spare parts management ready to go.

Other systems could benefit by importing COBIE as well. Building owners often run many Line-Of-Business (LOB) systems, often selected by different parts of the company, from different vendors. Asset Management, Capital Renewal, and the Registrar’s Classroom Scheduling, each has its view of the core facility information in COBIE. An owner may outsource maintenance to several different businesses that need to share information. The enterprise scheduling software, used to schedule staff and meetings, has its own view of the same data. If each system is initially configured through the import of the same COBIE data set, if each system uses the same identities for spaces and systems, then these systems will be ready to exchange Service calls sharing expectations and requests.

Operational BIM Schedules and Pre-Design Programming

As Chair of WS-Calendar, I receive a number of inquiries about the incorporation of time and schedule into other specifications. In particular, the wider visibility of VAVAILABILITY is attracting some interest. Occasionally these include fragments of xml, and inquiries as to how to apply this information.

WS-Calendar recently completed its third public review and will soon be published as Committee Specification 1.0.

Facility Programming is an important early step in step in the Integrated Design Process. Programming is defined in the Whole Building Design Guidelines (WBDG) as “the research and decision-making process that identifies the scope of work to be designed.” Programming is the first part of the design cycle, during which systems and space requirements are identified by the activities they will support. If the design process is compliant with the formal BIM process (BuildingSmart, NBIMS, etc.), then these systems and spaces are identified as described in the IFCs.

BIM is a collection of information sets and models with identified interfaces / information exchanges between them. A model that is of growing interest is the building’s energy model, which is today derived from a combination of structural and purpose models and [normally] a side questionnaire about the building’s use.

I have recently received early sketches (XML Fragments) of programming documents from Dr. Chris Bogen (Engineering Research and Development Center) in which building services and systems, as expressed in open buildingSMART model format, are included in vavailability to express, for example, the operating schedules of systems supporting dining facilities (and their energy requirements). The ERDC project is aiming toward the development of a format that can be used to compare the expected resource use of a facility during design and express the actual resource use identified through analysis of building sensor systems. With the additional pattern detection algorithms under development at the lab, ERDC expects to have a tool that will compare building use to identify when the use of a building doesn’t match it’s design prediction. The ultimate goal of this work is to create building simulators directly from data provided during traditional design and construction processes.

Over time, many buildings are found to have different energy use profiles then their models predict. Often this is due to changes in operating schedules from that which was predicted. We are beginning to see mandates to update these energy models to match actual results, particularly in government owned or funded facilities.

Lifetime maintenance and updating of these programming documents, including changing the operations schedules, establishes a baseline to compare predicted vs. actual use, and to thereby sooner to detect anomalies due to system degradation or misconfiguration.

An advantage of potential automated modeling within incorporated vavailability, is that schedules can easily be understood and manipulated by building operators/occupants. Once an energy model is in-place, it would be straight-forward to iteratively try out different systems schedules and examine different energy profiles. As we move to dynamic markets, the capability to project different times of use and compare those to projected energy prices might become a new source of value to building operators.