Commercial Use of Live Energy Models

This is one of a series of posts on how the semantic expression in WS-Calender is beginning to affect buildings and smart energy. WS-Calendar recently completed its third public review and will soon be published as Committee Specification 1.0.

In a previous blog, I discussed new directions in commissioning; including commissioning that incorporates BIM, schedules, and continuous energy models.

Performance Contracting and the new Commissioning

Many building owners are suspicious of energy performance contractors because the performance contractor is both a player and a score keeper. Because a significant effort is required to understand the information in building systems, there are significant start-up costs. These costs, both in money and time, require that each contract include a significant minimum contract lengths over which to amortize the up-front costs. These up-front costs make it uneconomical for energy contracting to use a third party auditor to verify results.If the owner selects a new a new performance contractor, the up-front costs will be incurred again.

Standard semantic tags and ready access to a light-weight BIM can change this.

Imagine a market wherein a cloud-based energy performance contractor could offer same-day initial reports. That same market also supports a number of 3^rd party auditors, cloud-based, each able to independently assess the results of the performance contractor. Each of these parties can hook up to the BSI, read the BIM, read the tags, and begin analyzing right away. A potential energy performance contractor could offer the building owner a selection of third party auditors to report the success of the contract.

This competition between cloud-based services would drive rapid innovation. On one side driving costs down, on the other driving richer models. These models are likely to build upon two significant efforts currently underway. ASHRAE SPC201 would inform the models, and through the linkage of systems and space, become more nuanced. Schedule-based business assertions, as we are beginning to see in the links of WS-Calendar and the IFCs would make these models more business aware.

Continuous commissioning based on such a foundation would support an ecosystem of cloud-based service suppliers, each able to grow to scale.

Retail use of Live Energy Models

As we move in this direction, we move from information models that are tuned to reflect changed operating hours to models that can tied increased energy use to short term activities, including, say those associated with a sale in one portion of a store. That portion of a store with an ongoing sale may have increased HVAC driven by increased traffic or brighter lights to attract shoppers and display the merchandise, and other enhanced amenities. A side effect of the brighter lights may be increased heat load, thus causing still more HVAC requirements than at first expected.

The most respected retailers with superior operations are already using these sorts of models to fine-tune their special Sales.

Non-Energy adaptive re-use of new Energy Components

Because the approaches described above rely on the composition of multiple standards, they create components that building integrators can re-assemble to meet other purposes.

Emergency responders have long wished for a variety of interactive means to acquire situational awareness of the facilities they are entering. The standard light-weight building model described above is a natural basis for situation awareness sharing. During an emergency response, the goal may be closer to raw sensor readings than to energy use. Those sensor readings, like the performance information, cannot be interpreted without a framework that indicates the spaces and the business purposes where those sensors are located.

Common abstractions, business purposes, and frameworks are the foundations for policy-based interactions with any system. The business-purpose-based analysis of space and system and schedule, is a likely target for adaptive reuse for emergency-response based policy. In the simplest (and direst) case, the facility is on fire, every asset is at risk, and so every bit of information about a building might be shared. In a simpler case, if the Spill Response Team is responding to a minor spill in the warehouse, it is inappropriate to share with them acess to, say, a webcam in the executive suite.

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.

Big Data, Buildings, and the Internet of Things

Big Data is the hot new buzz-phrase for something that buildings system integrators have long struggled with. Last Thursday (3/29), the White House Office of Science and Technology Policy (OSTP) launched its public initiative on big data for government, the Big Data Research and Development Initiative.

The purpose of big data is to support analytics, that is the massive crunching and correlating of data to find patterns. Early targets of the initiative include:

• putting the government’s own data sets into open formats
• pushing states to include a data or statistical literacy component in their education plans
• establishing ways to continuously collect data on prescribed topics as opposed to relying on temporary snapshots

The real time use of big data that is most commonly in the news click-stream and advertising analytics. This back-room technology only makes the news when there are privacy violations. Big data analytics are why Google is now in a death-match with Facebook, and why the European Union is in a privacy face-down with Google.

In government, the best known big data analytics are in security and crime prevention. Einstein systems gate all information in or out of each cabinet-level department, searching for patterns that indicate intrusion. The NSA and FBI are doing something with big data; the NSA may or may not be consolidating information on all internet communications at its Utah Data Center.

Buildings have long struggled with big data. They are not designed for storing or to processing too much. System instructions regularly warn to minimize trend reports. Product from a number of leading makers of environmental controls struggle with monitoring just a small portion of the buildings on the UNC campus. Building systems houses all aim at cloud-based analytics in their next release, but each that I have seen struggles with pushing information to the cloud. I have watched very fast networks struggling to handle data collection from a 100 buildings, and watched data edifices crack under the hundreds of gigabytes they produce each week.

We are just now entering the period in which the internet of things (IOT) becomes real, and the IOT stores its data in the cloud. Last month, Ninja Blocks (http://ninjablocks.com/) got its initial funding. Ninja blocks are consumer sensors that are as cheap as X10, and send their data to the cloud. Ninja blocks use open source hardware (download schematics from the site) to sense their environment: acceleration, temperature, current, humidity, motion, distance, sound, light and even capture video. You can create and sell your own Ninja Blocks to connect to the Ninja Cloud.

The Ninja Cloud connects this sensor information to social and cloud services. Sensor events can send tweets, SMS, or email. Ninja photos and video can move automatically into Facebook or Dropbox. The user plugs in a Ninja Block and then uses the web to develop scripts in the Ninja Cloud using point and click.

This may not be the same as energy management, but one of the more successful campus energy projects of recent years set up Facebook pages for buildings on the University of Mississippi campus. Students were encouraged to friend the buildings; systems in the buildings tweeted their energy use. The project raised Student awareness.

Ninja Blocks is a new company. They can probably do most of what they claim. Their team of entrepreneurial young engineers seems smart, quick, and committed. Their business plan is inspired using open source hardware to let others create new value sources for the Ninja Cloud. Still, I wonder whether their approach will scale well. They may hit the same wall that I have seen, when too many sensors are continuously logging too many points to the cloud.

Whether or not Ninja Blocks makes it, they are the future. Other start-ups, such as the Bluetooth-based, open source i-voltmeter will change the way we think sensors work. The data gathered by the internet of things will make its way to the cloud, where it will be Big Data. Building systems that do not participate will find themselves pushed aside.

The value of Big Data is in re-purposing and in re-use. The cost of gathering big data is going down, and will continue to go down. The Big Data from buildings will accumulate at an astounding rate. The value of Big Data will be in continuous re-harvesting for more information, the way click-streams and advertising are harvested again and again. Building operations and failure predictions are only the start.

Big Data from Building systems must learn to share well with others. This industry must consider its own version of the federal goals: open formats for data, better statistical literacy in systems, and the methods to collect and store very large volumes of data loom large. We may need to use the common semantics from Project Haystack as a common ontology for our big data. It will be mandatory to share with the Big Data from the IOT, both to accept IOT data into Building Clouds, and to send Building data into the IOT clouds, including the Ninja Cloud.

It will be a fast ride. Into the Clouds!

BSI Part 1: What is the Building System Interface?

After the ASHRAE meetings, and during the AHR conference, several of us are getting together to discuss building system metadata. The goal is to define interfaces to support quick fast integrations of building systems into the wider world. This is the first of several posts describing this interface. Drop me a line or watch for announcements from LONmark if you want to join us for discussion.

In my smart grid work, I began describing each end node as a microgrid. A microgrid is a self-contained entity responsible for managing its own energy use, generation, storage, conversion, and as a last resort, market operations. This model eliminates direct grid control of buildings. Maximum grid incentives, all delivered to a single energy services interface (ESI), the locus of market bidding for the building.

The ESI is the external face of the participants in smart energy. The ESI facilitates the communications among the entities that produce and distribute electricity and the entities that manage the consumption of electricity. An ESI may be in front of one system or several, one building or several, or even in front of a microgrid. In keeping with service integration principles, there is no direct interaction across the ESI.

Today, an ESI is most often on the outside of a building system. The leaders in commercial energy management, companies like Target, put the business between the ESI and the building systems. Target evaluates energy use, and changes in energy use as normal business decisions, and building systems respond to business operations. Target though, is unusually aware of its decision processes, has many nearly identical buildings, and has strict commissioning standards. For the rest of us to be like Target, we need a Building Systems Interface (BSI).

The BSI must expose several services. New systems will certainly incorporate the market-oriented interfaces of smart energy, for use inside the building microgrid. Other services will interact with the business, linking corporate calendars to building operations. Another will request and consume weather information; if nothing else, a data center should take advantage of a cold winter such as this to limit cooling loads.

Systems must tie their information to the space that the enterprise inhabits. It is not enough for points to self-describe themselves as an air handler—that air handler must describe itself in terms of the service it provides to a particular space. Space is what the building systems support, space is what the tenants recognize.

There is an enterprise service that links between the occupants and their activities and the BAS and its performance. It communicates to support business activities while using the common schedule communications developed for smart grids. It is aware of the market conditions and deals made with the grid though the ESI. It knows whether the volatile energy of the renewables-based grid is scarce or abundant. It can report back to the enterprise how and where energy is being used right now.

Even live-load, or plug-load, must be able to describe itself in relation to space. Panel sub-metering and BIM-based circuit tracing (PLie – panel layout information exchange) put even the coffee pot and copier as part of the BIM model for energy use. Even home appliances must be participants.