[Thanks to Supriya Goel, PNNL for your input!]
BuildingSync might just be the first major advance in how we report energy audit results in a long time. I say this cautiously because I’ve seen plenty of prior efforts fall flat, and I’m a born skeptic at heart. I’m literally from Missouri, the “show-me” state – the only state I know of that has chosen skepticism as it’s state motto. Couple that with the state’s other signature export, the Missouri mule, the embodiment of stubbornness, and you have a powerful recipe for resisting change. But I digress…
“I think BuildingSync can succeed where others have failed because the focus is on developing a language, not a tool.”
So why am I so hopeful the BuildingSync can change the way we report energy audits? Because the focus this time is on developing a language, rather than developing a tool. Those of us who’ve been doing energy audits for their whole careers have seen a lot of attempts to make the energy audit process more streamlined or automated. And most of those efforts have resulted in making things more cumbersome, rather than easier. I’ve seen several audit tools (usually created by software folks rather than energy auditors) that required way more baseline data that we normally collect. For example, a tool that we developed (prior employer) to do lighting audits, needed, not only a list of lamps, but a list of fixtures, ballasts, and lamp-ballast combinations, a rate library, etc. in order to accurately estimate energy and cost savings. Once you start building up all the possible combinations, the freedom of a clipboard and a blank sheet of graph paper is pretty hard to give up.
So why have so many energy audit tool efforts failed? What have they lacked? In a word, flexibility. In order to be cost effective on site, an energy auditor needs the flexibility to dig into details where opportunities are present, and skip over details where they aren’t. All the auditors that I’ve spoken to do quite a bit of “following their nose” on site. That’s not random or unprofessional – just the opposite. They know from experience where the greatest opportunities are, what the building owner is interested in, and what can realistically be retrofit. So that valuable time on site needs to be focused on the intersection of the needs and opportunities in that building, not blindly collecting enough data to model the whole building on day 1.
The problem with most attempts to streamline energy audits is that they focused on tools instead of languages. We don’t need a new comprehensive list of chiller types, or lighting fixtures, or even energy efficiency measures (more on that later). What we need is a common platform, a language really, for communicating data about buildings, energy efficiency measures, and what recommendations that have been implemented. That’s exactly what BuildingSync was designed to do.
So what exactly is BuildingSync if it’s not a tool?
The National Renewable Energy Laboratory (NREL), where BuildingSync was developed defines it as “A standard language for commercial building energy audit data that software developers can use to exchange data between audit tools.” More technically speaking, it is an xml schema, a subset of the larger Building Energy Data Exchange Specification (BEDES), which defined how to formally describe the elements in an extensible markup language (XML). The schema is basically a definition of how to encapsulate the data in a consistent way so that it can be shared across multiple tools and applications. In this way BuildingSync takes a fundamental approach. It defines how we share and communicate data, instead of trying to do all the jobs we might want to do with that data within one tool.
If you’re having a hard time getting your head around XML, just think of world wide web. Hypertext Markup Language (HTML) is an example of an XML that’s gotten really popular to use. Maybe you even know parts of the schema yourself. When HTML was created, it defined common elements and tags for representing them. For example, if I want the page title to be “BuildingSync Rocks” then you said it like this; <title>“BuildingSync Rocks”</title>. Then your browser read that data and put that title up at the top of your page. And the google search bots grabbed that and associated that title with your content. And your website-authoring tool was designed to spit out that html when you highlighted that text and clicked on the “Title” format. Once html was in place, it allowed the creation of a lot of other tools that made the web so powerful.
No more data dead ends
I can’t tell you how many energy projects that I’ve done or how much data I’ve collected on buildings that is virtually useless for any research. We have a terrible record for keeping track of information from audits – there is valuable data in a million different reports, in different formats, in a million spreadsheets, unsearchable and thus useless to any kind of meta-analysis. These are what I refer to as “data dead ends” and we need to quit abandoning our valuable data on them. With today’s big data analytical techniques, what could we do with that data? A lot. Let’s stop building data dead ends.
We wrote the new ASHRAE Standard 211, and its accompanying reporting forms to [more or less] align with BuildingSync. I say “more or less” because, since both were developed during the same time frame, they were both moving targets. ASHRAE’s committee on 211 will continue to hone those reporting forms to improve usability, and facilitate data capture through BuildingSync XML (or BSXML). We’ve also added optional reporting forms that, once included with required energy audit parameters, will provide sufficient information for a basic model of the building in PNNL’s Asset Score tool. This means that, by reporting a few extra parameters, you’ll be able to automatically generate a crude model of your building. Energy modelers out there will no doubt cringe at that thought. But those models at lease provide a base case to start from, and guiding information about the efficiency of the energy assets in the building.
Imagine the potential for saving time under a mandatory energy audit or retro-commissioning program. If the auditor uses the new Standard 211 forms for reporting energy audit data, we will be able to export that data using BSXML. The city could then use a reporting tool that reads BSXML input files. In fact, DOE has already developed an open source tool that establishes just such a platform; the Standard Energy Efficiency Data Platform™ (SEED Platform). SEED is free, open source, and connects to other tools such as EPA Portfolio Manager™, Green Button, and the DOE’s Commercial Building Energy Asset Score.
You might think that the needs I’m referring to here are already addressed by other schemas, but I haven yet seen efforts that fit our needs. Building Information Modeling (BIM) is too granular and represents what is, not what is proposed or considered. GreenButton XML helps with building utility data, but omits any real data on the building or systems. Various modeling programs have means of representing buildings for thermal and energy modeling, but there is no common open standard for communication. A common way of representing energy efficiency measures, costs and savings is still lacking, and the value to building owners, engineers and energy efficiency program administrators is huge.
The Tricky Part
Well, so far this all sounds so great that maybe you’re wondering why we’re just now getting around to using an XML schema for energy audit data. What I call the “tricky part” is the question of how much you try to define and standardize. You want to go “deep” enough to provide value and bring some consistency to the chaos. But you also don’t want to over-specify the language – you could end up unwittingly limiting what the conversation is about.
One example of where we hit “the tricky part” for me is the issue of energy efficiency measures. It might be tempting to define a set list of standardized energy efficiency measures, based, for example, on the type of equipment you see in the building. There could be a lot of power in doing so – it would allow you to compare energy savings for the same measures across various building types, occupancies, weather, etc. However, creating such an “enumeration” (in XML speak) could also create problems. What happens when technology evolves faster than our language? We wouldn’t want to limit the energy efficiency measures reported for a site simply to those measures that have been done in the past. Suddenly I see our energy auditor reaching for his clipboard and blank sheet of paper again.
Another tricky part is the fact that the success of BSXML depends on the number of tools that adopt BSXML and support data exchange through BSXML. GBXML (not green button but green building XML) has finally reached the stage where many building design software tools support data exchange through its schema. But BuildingSync still has long way to go.
So stay tuned and I suggest that you think about how the encapsulation of energy audit data might be useful to you. I, for one, would love it if I didn’t have to create a brand new energy audit template for every client and I see BuildingSync, and it’s compatibility with Standard 211 as a way to get there.
Finally, a brief update regarding Standard 211 on Commercial Building Energy Audits; our ASHRAE committee has voted to publish and <fingers crossed> we hope to be in the ASHRAE bookstore by the June meeting in Houston </fingers crossed>.
Like this post? Share it on LinkedIn.
