ASHRAE Building Energy Quotient (Building EQ) Website

ASHRAE Building Energy Quotient (Building EQ) Website

ASHRAE’s Building EQ Web Portal provides a quick energy analysis that benchmarks a building’s energy performance. Building EQ assists in the preparation of an ASHRAE Level 1 Energy Audit to identify means to improve a building’s energy performance including low-cost, no-cost energy efficiency measures and an Indoor Environmental Quality (IEQ) survey with recorded measurements to provide additional information to assess a building’s performance.

Two different evaluations can be used independently to compare a candidate building to other similar buildings in the same climate zone or together for an assessment of a building’s design potential compared to actual operation:

In Operation compares actual building energy use based on metered energy information.

As Designed compares potential energy use based on the building’s physical characteristics and systems with standardized energy use simulation.

The Old Way

When Building EQ was first introduced, building owners and engineers could submit information about their candidate building to ASHRAE using an Excel spreadsheet template. This was a very inefficient way of doing things. It involved filling out the required data into a spreadsheet, and then uploading the spreadsheet(s) to the ASHRAE Building EQ website. Then, ASHRAE personnel would open the spreadsheet and determine whether the data was valid, and if it was, what rating to assign the building. The spreadsheet method was wrought with many inefficiencies including:

  1. If data was missing or invalid, the spreadsheet would be sent back to the building owner to be corrected. This involved working with multiple versions of the spreadsheet which could very quickly become confusing and could potentially result in working with outdated and incorrect data.
  2. ASHRAE personnel would validate all of the data manually, which was a slow and inaccurate process.
  3. There were no links within the spreadsheet to ENERGY STAR Portfolio Manager that would allow users to migrate data to/from other programs into bEQ.
  4. The spreadsheet was only in IP units.
  5. Many more inefficiencies too numerous to list here

The New Web Portal

In 2016, Carmel Software was hired to develop the web-based user interface that would solve all of the problems above and introduce even more efficiencies and features that a spreadsheet could never provide. In addition, Carmel has tasked to develop a website that would be able to accommodate many types of connected devices including Windows and Mac desktops/laptops, all iOS and Android mobile smartphones and tablets. After about 9 months of development, the ASHRAE Building EQ portal was officially launched, and it has been a resounding success. More project submissions were made within the first 2 months of the website launch than within the first 5 years of existence of the Building EQ rating system with only spreadsheet submissions. As of November 2019, over 500 projects have been submitted.

What Does Building EQ Measure?

The Building EQ rating system rates building energy usage only. It is not meant to compete with LEED which measures far more including water usage, material sourcing, and much more. The Building EQ rating system works as follows:

  1. Based upon the building type, climate zone, and heating and cooling degree days, a lookup for a benchmark value is performed using an ASHRAE Standard 100 site median table derived from CBECS (Commercial Building Energy Consumption Survey) 2012 building energy usage data. This usage data is expressed in units of energy use intensity (EUI)  which is the amount of energy used per square foot per year.
  2. The user then enters a year’s worth of utility data and the total square footage of the building to calculate the specific building’s EUI. This building-specific EUI is compared with the normalized benchmark EUI  and a Building EQ score is derived by dividing the two numbers then multiplying by 100. The range of the score is from 0 to 200 where 0 is the most energy efficient and 200 is the least. A score below 100 is considered energy efficient since the specific building beats the benchmark EUI derived from CBECS.

Additional Inputs

There are many additional inputs in the ASHRAE Building EQ web portal above and beyond those that are used to calculate the Building EQ score. Below is a list of these additional inputs for the In Operation method:

Building Performance Credentials

The “Building Performance Credentials” section allows the user to input any other ratings or scores the building may have received including Energy Star, LEED, Green Globes, and more.

Building Performance Chars

IEQ Screening

The “Indoor Environmental Quality Screening” tab includes a number of accordions (sections) that allow the user to input additional information about the building.

The objective of the building indoor environmental quality (IEQ) screening is to verify that the IEQ of the building as it affects the occupants has not been obviously compromised in the pursuit of energy efficiency and energy savings. The screening is intended to go beyond professional judgment with the inclusion of actual measurements. The measurements are focused on areas identified in the screening and are therefore representative of the building spaces and not intended to be all inclusive. If no issues are identified, the Assessor should take representative spot measurements throughout the building in order to provide feedback to the building owner/operator. Representative space types may be determined by space type (office, conference room, corridor), by space usage (different tenants or floors), or by space system type (building served by multiple system types). The information is provided to the building operator for follow-up actions and to benchmark, evaluate, and diagnosis building systems that affect indoor environmental quality including thermal comfort, lighting quality, and ventilation for indoor air quality. The IEQ screening is not intended to serve in the place of a full IEQ evaluation performed by an expert in that field. For this reason, it is important that the building owner follow up separately on any deficiency or potential problem noted on the forms by having a full IEQ evaluation performed by a qualified professional.

Indoor Environmental Quality

Energy Efficiency Measures (EEMs)

This tab allows the user to input any energy efficiency or conservation measures that have been implemented. The measures are divided by category: Building Envelope, Lighting, HVAC, Refrigeration, Energy Generation/Distribution, Other). Within each accordion is a drop down with a list of pre-populated measures.  These measures are outlined in Informative Annex D and Informative Annex E of ASHRAE Standard 100-2015. The measures are divided by category: Building Envelope, Lighting, HVAC, Refrigeration, Energy Generation/Distribution, Other).

Building EQ EEM Categories

The user is also able to enter a cost range and payback period for each measure.

There are 3 additional inputs in each accordion that allow the user to input their own custom measure descriptions along with cost ranges and payback periods.

Building EQ Example EEM

Photos and Attachments

This final tab allows users to add photos and attachments along with descriptions and categories. These photos will appear in the narrative report.

Building EQ Photo Tab

Building EQ Reporting

Standard 211 Audit Spreadsheet

Building EQ does something else that no other rating system does: It works closely with ASHRAE Standard 211 – Standard for Commercial Building Energy Audits. This is an ANSI standard that formalizes the process of performing building energy audits. ASHRAE Standard 211 protects a building owner/operator’s energy audit investment by providing an outline for auditors and offering best practices that ensure quality audits. It sets forth requirements for the experience and credentials of energy auditors, specifications for compliance and clear definitions of the audit processes and scope.

A Standard 211 audit spreadsheet is included along with the actual text of the standard. This spreadsheet allows users to fill in all information related to Level 1 and Level 2 energy audits.

Remember, the primary function of an energy audit is to identify all of the energy streams in a facility in order to balance total energy input with energy use. The ASHRAE Level 1 is a simple and quick audit that requires a brief review of building operating characteristics. It mainly identifies low-cost/no-cost measures and will only uncover major problem areas. Level 1 audits are a great way to prioritize energy efficiency projects and to assess the need for a more detailed audit. The ASHRAE Level 2 audit includes the Level 1 audit plus more detailed energy calculations and life cycle cost analysis of proposed energy efficiency measures. This type of audit identifies all energy conservation measures appropriate for the facility given its operating parameters. 

Much of the information required to fill out the Level 1 inputs in the audit spreadsheet are already inputted into the ASHRAE Building EQ web portal. Therefore, the portal allows the user (for a fee) to create a Standard 211 spreadsheet with many of the Level 1 inputs pre-populated. Even though the spreadsheet also includes Level 2 parameters, Building EQ does not include most of the information required for Level 2 audits. Therefore, this information needs to be manually filled in.

Below is a screenshot of one of the tabs in the Standard 211 Excel spreadsheet:

ASHRAE Standard 211 spreadsheet

ASHRAE Building EQ Label

Once a Building EQ project is approved by ASHRAE personnel, the user is able to print out a Building EQ label that includes the Building EQ logo along with a sliding scale showing the final Building EQ score. The following is an example of the Building EQ label:

Building EQ Label

Building EQ Energy Audit Narrative Report

This Microsoft Word doc report provides a template for an ASHRAE Level 1 Energy Audit that follows the information in Section 6 (Reporting), Annex C (Reporting Forms), and Annex D (Report Outlines) in ASHRAE Standard 211.  The template provides recommended text and boiler plate language to assist the user in preparing a comprehensive report and is automatically populated with information collected and entered into the Building EQ Portal as part of the Building EQ In Operation assessment process. The recommended text can be edited as needed by the user. The audit specific information populated from the Building EQ Portal is shown in filled-in tables in the report. Below is an example of two pages of the report:

ASHRAE Building EQ Narrative Report

Additional Functionality

The Building EQ portal includes additional functionality that helps expand its usefulness:

Integration with Energy Star EUI Data

Depending upon the building type that the user selects, the energy utilization index (EUI) data will either be pulled from ASHRAE Standard 100 database in Building EQ or from an Energy Star service hosted by Architecture 2030 Zero-Tool. Each Energy Star building type has a different set of parameters associated with it so the user will be prompted to input many different types of values. Once the user has inputted all of the required information, pressing the “Get EUI Values” button calls a remote calculation engine that retrieves the appropriate Energy Star EUI value based upon the building type and parameter inputs.

Energy Star

Integration with Energy Star Portfolio Manager

For electricity, natural gas, and other “non-delivered” fuel types, the user can import utility data that already exists in Energy Star’s Portfolio Manager software. All the user needs to do is export the utility data from a PM project to a .csv file. Then, import the .csv file into the appropriate fuel type. The data should be monthly for one year taken within the past 18 months.

Building EQ Utility Data

Integration with BuildingSync

BuildingSync® is a common schema for energy audit data that can be utilized by different software and databases involved in the energy audit process. It allows data to be more easily aggregated, compared, and exchanged between different databases and software tools. This streamlines the energy audit process, improving the value of the data, minimizing duplication of effort for subsequent audits, and facilitating achievement of greater energy efficiency.

Several tools utilize BuildingSync including U.S. Department of Energy’s Building Energy Asset Score. Asset Score is a national standardized tool for assessing the physical and structural energy efficiency of commercial and multifamily residential buildings. The Asset Score generates a simple energy efficiency rating that enables comparison among buildings, and identifies opportunities to invest in energy efficiency upgrades. Data exported from Asset Score (specifically Audit Template) via BuildingSync can be imported into BuildingEQ to populate relevant (but not all) data.

Building EQ Audit Template

Latest Stats

The following are the latest stats as of December 1, 2019:

Number of users: 998

Number of projects: 627

Average area of buildings analyzed: 69,392 sqft

To sign up for a free account, click here.

A Progress Report on gbXML Validation Efforts

A Progress Report on gbXML Validation Efforts

Overview

Carmel Software was hired by the National Renewable Energy Lab (NREL) to update and improve the Green Building XML (http://www.gbXML.org) schema, all in the name of improving interoperability amongst disparate building design software tools. This progress report summarizes the work completed over the past year.

Overall Goal and Objectives

The goal of this project was to validate the National Renewable Energy Lab’s (NREL’s) OpenStudio software tool to produce valid gbXML and also set the stage to validate other BIM and building analysis software tools in the future. There were three main objectives of this validation work.

  1. The first objective was to demonstrate that the OpenStudio software could pass the gbXML validation procedure.
  2. The second objective was to encourage other software vendors to certify their software using the validation procedure as well.
  3. The third objective was to work towards a generic validator that could be used on general user models, as opposed to the strict test case models required by the gbXML validation procedure. Delivering a fully working validator was out of scope of this work, therefore requirements were developed to set the stage for future work.

In support of the first objective, we developed OpenStudio models which represented the buildings in the validation procedure test case. These models were generated programmatically using the OpenStudio Ruby Application Programming Interface (API) to reduce maintenance costs and to allow them to be leveraged for other purposes. OpenStudio passed the validation procedures and is now the first software authoring tool to officially become “gbXML certified” (http://gbxml.org/OpenStudioCertification_Latest ).

In support of the second objective, we drastically improved the validation website, documentation, and tools required to apply the validation procedure. We publicized the validation procedure and encouraged gbXML software vendors to apply it to their tools. This required contacting other gbXML software vendors directly as well as making public announcements, conducting live webinars, and promoting other ways to generate user interest in the validation efforts. We publicized the state of the OpenStudio validation efforts to encourage other software tools to apply the validation procedure to their own tools. In addition, we simplified and streamlined the validation process to allow the process to be both more responsive and clear to market demands, while also allowing room for future growth of test cases. In fact, Autodesk will soon be validated to Level 2 compliance (see below) and is working with gbXML.org on Level 3 compliance.

In support of the third objective, we developed requirements for a generic validator. User stories were developed and preliminary mockups were made. The most important user story developed was to allow a user to upload their gbXML file to the gbXML.org website and view a 3D representation in their web browser. This would allow the user to identify any problems with their model visually. The second use case was for software to detect certain classes of problems with the user’s model and identify those visually in the 3D display. Finally, the use case of upgrading user models to the current gbXML schema version was identified.

Tasks

Here are the tasks that were performed to achieve the above objectives:

  1. Developed OpenStudio Models for Validation Procedure
    We developed OpenStudio models for a number of the buildings in the validation procedure test suite. The test cases were derived from the ASHRAE RP-1468 documentation. The models were programmatically generated using the OpenStudio Ruby API. All scripts and model content developed for this purpose were developed under the Lesser General Public License (LGPL) open source license and are maintained in a public repository on github.com (https://github.com/GreenBuildingXML/openstudio-gbxml-validation ).
  2. Validated OpenStudio gbXML Export/Import
    We applied validation procedures to each of the OpenStudio models developed in task 1. We verified that each of the validation test cases imported correctly into the OpenStudio SketchUp plug-in. We also addressed any issues with the validation software that were found in this work. For example, the OpenStudio validation forced gbXML.org to address geometry created by thin-walled geometries, and metric-only software. Previous versions of the validator only addressed thick-walled geometry engines, and supported IP-units. The validation process and OpenStudio were made more robust as a result of this process.

    Highlights of improvements/fixes to OpenStudio as a result of this project:
    • correctly specifies SlabOnGrade elements
    • correctly handles area calculations of sloping floors and ceilings (before calculated area as zero)
    • handles most second-level space boundary translations, automatically, for simple geometries
    • gbXML export up-to-date with version 6.01 of gbXML

    Highlights of improvements/fixes to gbXML validation as a result of this process:
    • unit of measure handling
    • special procedure development for thin-walled geometry creators, opening up validation to a wider audience
    • improved validation website user interface and user experience
    • better error-handling and user messaging when validation fails
    • improved geometry validation engine

  3. Improved Validation Website and Documentation
    The previous validation website was not hosted on the gbxml.org domain which reduced its visibility and credibility. For this task, we moved the gbxml.org website to a hosting platform that supports the validator software. The gbxml.org website was redesigned to more prominently display the validation procedure and documentation. The website now shows which software tools have been validated or are in the process of being validated. See http://www.gbxml.org for more details.
  4. Promoted gbXML Validation Efforts
    This task was performed in parallel with other tasks listed above; the purpose was to keep other software vendors and the public up to date on gbXML validation efforts. We attended the four day SimBuild 2016 Conference in Salt Lake City in August 2016 to promote gbXML validation efforts. In addition, we conducted two live webinars to explain our work.
  5. Generic Validator
    Delivering a fully functional generic validator was out of scope for this work. Therefore, work on this area was focused on developing user stories and requirements for future work. The most important user story developed was to allow a user to upload their gbXML file to the gbXML.org website and view a 3D representation in their web browser. This would allow the user to identify any problems with their model visually. The second use case was for software to detect certain classes of problems with the user’s model and identify those visually in the 3D display. Finally, the use case of upgrading user models to the current gbXML schema version was identified.

    Integration with the Autodesk Forge API was investigated as a potential solution for viewing user submitted 3D models. However, this is still a work-in-progress since the Forge API is in beta phase.

Significant Findings and Issues

During this project, we decided that 3 levels of gbXML certification, or compliance, were required to provide more clarity to the community of users and vendors.:

  1. Level 1 compliance involves validating that a gbXML file is a well formed XML (per the W3C ISO Standard) and also conforms to the gbXML XSD (from gbXML versions 0.37 to 6.01, depending upon which version the software tool currently exports).
  2. Level 2 compliance involves validating a gbXML file against 8 to 10 geometric “test-cases” that are based upon ASHRAE Research Project 1468, “Development of a Reference Building Information Model (BIM) for Thermal Model Compliance Testing”. Level 2 requires that second level space boundaries be correct for the simplest test cases, and pass a small subset of translation edge cases.
  3. Level 3 compliance has yet to be fully defined. However, Level 3 does involve certain levels of vendor tool automation that goes far above and beyond Levels 1 and 2 compliance. We are currently working with Autodesk to better define Level 3 compliance (See the Future Work section for more details).

List of Issues

OpenStudio passed the following test cases:

  1. Test Case 3: Test for proper second level space boundary representation
  2. Test Case 6: Test for proper second level space boundary representation
  3. Test Case 7: Test for basic pitched roof representation
  4. Test Case 8: Test for basic sloped slab on grade representation
  5. Test Case 12: Test for proper second level space boundary representation
  6. Basic Whole Building Test Case 1: Test for proper second level space boundary representation

To pass these test cases, it did require that NREL make some updates to the OpenStudio SDK responsible for gbXML export since there were a few errors that were pervasive for every test case. Therefore, NREL needed to make some changes to the gbXML export feature of OpenStudio to be compliant with the validation process. gbXML provided NREL with guidance as to how each XML file should look in order to pass, which NREL took and made changes to their code base. In some cases, gbXML decided to relax configurable constraints, to allow the document to pass.
Below is the full list of issues and changes to the OpenStudio code base made as a result of this work effort:

  1. There were no BuildingStorey definitions in any export from OpenStudio. This is a required element, but we relaxed this for validation purposes.
  2. The Building->Area calculation that was done during export did not meet gbXML specifications for the Building Area calculation. To be fair, gbXML may not have the tightest definition in terms of the criteria for when a Space Area is included in the Building Area, but the point is, plenums and other non-occupiable spaces shouldn’t be included in the building area calculation.
  3. Any time there was a floor that was on-grade (industry standard is when z=0, and it seems OpenStudio follows this convention) we would expect the surfaceTypeEnum for that surface to be SlabOnGrade, but OpenStudio defines these surfaces as UndergroundFloor. This needed to be changed.
  4. Thin-Shelled geometry challenges: The fact that OpenStudio makes gbXML derived from a thin-walled geometry paradigm consistent with the building energy modeling paradigm as opposed to a BIM model posed a basic philosophical challenge for the validation process. Originally, the validator was designed for BIM-centric tools that have wall thicknesses inherent in the modeling environment. Autodesk Revit, for example, assumes that the wall thicknesses affect the volume and area calculations, even though the wall vertices go to the centerline of the thickness (as if the walls had no thickness at all). When we tried to use these same standard test files as a comparison point for a gbXML created via OpenStudio, we encountered an issue. Whereas we modeled the walls in OpenStudio as if they were on the centerline, with the same coordinates as the standard files, now the volume and area calculations came out differently than the standard files. Of course, if we tried changing things around and modeled the surfaces in OpenStudio at the inner wetted perimeter, we get the volume and area correct, but now the polygon coordinates are in a different location and don’t match the standard file PolyLoop coordinates. So either way, it is not a perfect process.
  5. Changes to the validator code base: We made several improvements to the validation engine itself, and also to the standard test case XML files as a result of this work that has already been incorporated into the latest version of the validator. We found two problems with the standard test case files: Occasionally, there were still errors in the files that should no longer persist by the end of this process. The whole building test cases, made at the end of phase two, were particularly problematic because we made them with Honeybee out of Grasshopper. Secondly, sometimes the decimal precision was pretty extreme because for all the other test cases we used Revit in US-IP units to create the test cases originally. This meant for sloping surfaces, there was sometimes units like 9’10-11/16” that made for some difficulties when re-creating the test cases. We tightened these up so for a majority of the test cases there was much less guess-work and complexities around the units of measure.

Future Work – New gbXML Features

Further Develop Level 3 Compliance
We will be working with Autodesk to achieve Level 3 certification, which has yet to be fully defined. It does involve certain levels of vendor tool automation that goes far above and beyond Levels 1 and 2 compliance. Autodesk desires to achieve Level 3 compliance for both Autodesk Revit and Insight 360. Some examples of Autodesk-specific Level 3 automation include:

  1. Handling ‘real’ architectural models i.e. supporting a very wide variety of modeling practices, coping with natural inaccuracies (small gaps / overlaps) and scaling from concept to detailed design
  2. Automatic perimeter / core thermal zoning
  3. Automatic identification of elements acting as shading (as opposed to room bounding) without manual definition
  4. Handling ‘Sandwich’ conditions i.e. when two or more elements are adjacent or very closely adjacent and often not perfectly parallel but essentially a single gbXML surface
  5. Definition of material thermal properties (which get very interesting when combined with sandwich conditions)
  6. Working with or with explicit room/space objects and their associate metadata
  7. Above / below grade
  8. Columns
  9. Openings
  10. Ceiling voids

Discuss the possibility of “use case” based validation. For example, what fields are required for the energy modeling use case (or maybe the OpenStudio use case)? What fields are required for the HVAC loads use case? See http://www.hpxmlonline.com/tools-resources/data-selection-tool/ for an example of this.

Develop a gbXML Conversion Tool
Both NREL and Autodesk have requested that we develop a simple software tool (web-based) that converts previous versions of gbXML (i.e. – 0.37) to later or the current versions since major tools such as Autodesk Revit continue to support the 0.37 version while validation only supports the latest version. This is not an easy task on the part of the software vendor to update to the latest version since tools like Autodesk Revit have long-term “wish-list to release cycles” (often 1 or more years). Therefore, developing a conversion tool will allow these previous versions of gbXML to update to later versions.


Develop a Generic Validator and Open-Source Geometry Engine

While we have successfully developed a test-case validation tool (http://gbxml.org/validator/Pages/TestPage.aspx ), we still need to develop a “generic” validation software tool that can be used by more stakeholders including energy modelers, engineers, architects, and others. This tool should be able to validate any generic gbXML, not just test-case gbXML files. We believe we are closer than ever to achieving this vision, however, there is limited time and budget to test such concepts. Developing unit tests, and making incremental improvements to this code base, is a full-time effort that is constantly in need of development efforts.
The software development effort taken thus far to develop vendor certification tools will be leveraged for the generic validator, one that can accept any user model. A web page shall be developed on gbXML.org so a user can upload their gbXML model and the validator shall determine if there are any defects. If there are defects, the website shall provide information to alert the user to any defects that were found. A web based 3D visualization tool may be provided to visualize the uploaded model and to identify the defects in a meaningful way. We plan on using Autodesk’s Forge Viewer API to translate the gbXML geometry into a web-based model.


Create a gbXML Portal and Accompanying Web Service

Along with the generic validator wish-list item above, another long-time goal has been to create a gbXML “portal” that allows users to register and upload gbXML files for remote storage. We would create a web service (or web API) that could be accessed by authorized software tools to import and/or export gbXML files to and from this portal. This would provide the following benefits:

  1. Different “dot” versions of gbXML could automatically be converted to the appropriate “dot” gbXML version that is supported by a consuming software tool.
  2. Different versions of the same gbXML file that is produced by a BIM authoring tool could be stored in the portal so that a consuming tool could easily re-import it and update any changed information. Think of it as a sort of “version control” function.
  3. If enough gbXML files are uploaded to the portal, we could begin to analyze the data and look for trends that may benefit the industry. For example, information from the uploaded models could be analyzed so as to gain insight on the use of gbXML in practice, e.g. which software tool authored the model and which defects were found.
Green Building XML (gbXML) Certification

Green Building XML (gbXML) Certification

Carmel Software is a member of the Board of Directors of gbXML.org which houses the Green Building XML open schema. This schema helps facilitate the transfer of building properties stored in 3D building information models (BIM) to engineering analysis tools, all in the name of designing more energy efficient buildings.

For example, an architect who is designing a building using a BIM tool such as Autodesk Revit is able to not only create the building geometry, but also assign properties to the building including lighting density, occupancy hours, wall and window properties, and much more. All of this information can be exported (or “saved-as”) as gbXML file that is then imported into a software analysis tool that predicts yearly building energy usage (such as Trane TRACE). The purpose of this integration is to eliminate the need to enter the same information into the analysis tool that is already available in the BIM tool.

It has proven so popular that almost 40 software tools world-wide have some type of gbXML integration. Click here for the list.

Recently, we have been funded by the US Department of Energy and National Renewable Energy Lab (NREL) to develop a suite of “test cases” that software vendors will need to undergo to become certified in gbXML. Certification is a process that gives vendors who produce gbXML a stamp of approval from gbXML.org:

image

Achieving Certification

How does a vendor achieve certification? gbXML.org has developed a series of test cases (in fact, just really simple building shapes) that each pose a new situation for the vendor to adhere to. In other words, the vendor is responsible for recreating a simple building shape in their own software tool. Then, they “save-as” gbXML and upload it to our validator software. If the building shape closely matches the test case gbXML file, then it “passes”:

image

What is being tested? For each test case, there are a number of items being “tested”, and it is all focused on geometry:

  1. Are
    all the surfaces in the right location and orientation?
  2. Are
    all the surfaces properly defined?  Walls
    are walls, floors are floors, interior/exterior etc. ?
  3. Is
    the gbXML “good”? i.e. – No typos, incorrect names, missing
    fields.

image

Example Test Cases

Test Case 2: A window test case (see image below)

  1. Single
    window is drawn
  2. User
    converts to gbXML
  3. Two
    windows are created
  4. Overhang
    is linked to both windows.

image

Test Case 3: A test case for spatial configuration. If a tool was to submit for compliance, but is not touting its automated capaibilities, then the wall types would be declared explicitly and exported to gbXML and submitted for compliance.

If a tool was to submit for compliance, but is advertising automated capabilities, then the wall types would not need to be called out, and the translation to a thermal representation of the building in gbXML would happen automatically:

image

Test Case 5: Here is an example of a test case (see image below):

  1. Single
    volume is drawn
  2. User
    converts to gbXML
  3. Walls
    automatically separated
  4. gbXML
    shows 8 walls (4 above and below grade)

image

Test Case 6: If a tool was to submit for compliance, not touting automated capabilities, then the wall types would be declared explicitly, and then exported to gbXML and submitted for compliance.

If a tool was to submit for compliance, but is advertising automated capabilities, then the wall types would not need to be called out, and the translation to a thermal representation of the building in gbXML would happen automatically:

image

Levels of Certification

There are 3 levels of gbXML certification:

  1. Direct translation with no automation
  2. Basic automation where:
    • Surfaces are all defined and correctly converted
    • gbXML is valid XML
    • gbXML is legal gbXML as per the XSD
  3. Advanced automation where geometry from the authoring tool to a BEM-ready model with basic automation

Level 1 and Level 2 test cases are essentially the same. The only difference is whether the tool makes it easier, through automation, to identify surface types without the user having to do it manually.

Level 3 test cases are new industry reach goals. No tools on the market today can achieve all of the Level 3 Test Cases. These are advanced benchmarks.

The total number of test cases is in flux. We expect that our user community will send emails asking for more test cases when they find a flaw in vendor software.

All test cases must be passed to achieve a full “Level 1”, “Level 2”, etc. certification.

See the image below for more information on the levels of certification.

image

Example of Certification Process

Our first validation customer has been the National Renewable Energy Lab (NREL). We have been working with their OpenStudio software tool which works on top of EnergyPlus to calculate yearly building energy usage. OpenStudio has enountered some difficulty in passing all of the tests. The reasons for this are two-fold:

  1. The nature of some of the test cases are beyond OpenStudio’s intended scope
  2. The validator has also been found to be too stringent

Some of these stringency issues include:

  1. No allowance for metric units, or mixed metric and I-P units
  2. Ambiguous acceptance of interior ceilings or floors
  3. Does the azimuth and lower left hand coordinate truly have meaning for horizontal surfaces?
  4. Handling geometry from egg-shell tools (e.g. – SketchUp, FormIt
  5. Handling geometry from tools with Interior Surface enumeration (Bentley)
  6. Better abstraction of wall polygons

Handling Different Types of Geometry

Handling Geometry From Egg-Shell Modelers (SketchUp, FormIt):
If all surfaces and zones are drawn on the centerline:

  • The surface vertices will be correct (because surface vertices are defined at the centerline)
  • But the area and volume calculations will be incorrect (when compared to a thick wall representation). Areas and volumes, by definition, must take into account wall thicknesses.

Solution: Tweak the validation process.
We will make special considerations for the
area and volume calculation if the vendor is
submitting for a geometry modeler like this.

image

Handling Geometry From Interior Surface Modelers (Bentley):
If all surfaces and zones are represented as interior:

  • The surface vertices will be incorrect (because surface vertices are normally defined at the centerline)
  • But the area and volume calculations will be correct (when compared to a thick wall representation). Areas and volumes, by definition, must take into account wall thicknesses.

Solution: Tweak the validation process.
We will make special considerations for the
area and volume calculation if the vendor is
submitting for a geometry modeler like this.

image

OpenStudio Validation Findings:
OpenStudio has encountered difficulty passing all the tests.

Primary:

  • The nature of some of the test cases are beyond OpenStudio’s intended scope
  • The validator has also been found to be too stringent

Secondary:

  • The current validation documentation could be improved, with more clarity
  • Validator interface could be improved to clarify why the test is passing or failing

gbXML is Proposing Changes to Simplify and Clarify Compliance:
OpenStudio has encountered difficulty passing all the tests.

Findings:

  • The nature of certain test cases is beyond OpenStudio’s intended scope
  • The validator is too stringent
  • Documentation needs to clarify what is being tested
  • Validator interface could improve to clarify why a test passed or failed

gbXML’s forward-looking position:

  • The number of test cases required to pass needs to decrease
  • The validator requirements will relax
  • Documentation is to be improved, and put online
  • Validator interface is also going to be improved to be more clear
Carmel Receives U.S. DOE Funding for Sustainable Building Design

Carmel Receives U.S. DOE Funding for Sustainable Building Design

Carmel Software is a member of the Board of Directors of gbXML.org which houses the Green Building XML open schema. This schema helps facilitate the transfer of building properties stored in 3D building information models (BIM) to engineering analysis tools, all in the name of designing more energy efficient buildings.

image

Here is a more layman’s explanation of what this all means:

Green Building XML (gbXML) is a schema or “language” that allows BIM (building information modeling) authoring software tools such as Autodesk Revit to communicate with building analysis tools such as Trane TRACE.

For example, a user is able to design a 3D virtual model of a building in Autodesk Revit. This model includes complete visual geometry of the building and information about the types of walls, windows, roofs, lighting and occupancy density. Since this information is required by building energy analysis software tools, it is redundant to re-enter all of it into a stand-alone energy analysis software tool when it is readily available from the 3D model. This is where gbXML helps: A software tool such as Autodesk Revit is able to “Save As” gbXML meaning that it is able to export all of its geometry and other building information into the gbXML language format. Taking this gbXML file, the user is now able to “import” this building information into software tools such as EnergyPlus or Trane Trace without manually re-entering all of this data by hand. The end result of all of this is that an energy modeler is better able to design more energy efficient buildings for purposes of, say, LEED certification.

In theory, the above workflow sounds seamless and attractive to anyone involved with modeling the energy usage of a building. In reality, the process is fraught with enough complications that energy modelers often forego this process in favor of more manual methods. These complications result from inconsistencies in how the various software tools integrate with gbXML.

Today, gbXML has the industry support of leading 3D BIM vendors such as Autodesk, Bentley, and Graphisoft. In addition, we have been funded in the past by the US Department of Energy and its various labs to further develop the gbXML schema and also better market it to industry stakeholders.

In the Fall of 2015, the National Renewable Energy Laboratory (NREL) agreed to fund Carmel Software to further improve the gbXML schema in the following ways:

1. Carmel will develop OpenStudio (NREL’s cross-platform
collection of software tools to support whole building energy modeling
using EnergyPlus) models which represent the buildings in the validation procedure test case developed in Phase I. These models will be generated programmatically using the OpenStudio Ruby Application Programming Interface (API) to reduce maintenance costs and to allow them to be leveraged for other purposes.

2. Carmel will improve the validation website, documentation, and tools required to apply the validation procedure. Carmel will publicize the validation procedure and encourage gbXML software vendors to apply it to their tools.

3. Carmel will apply the technologies developed for the validation procedure to a general use validation tool. This tool will be able to validate any generic gbXML file and, it will also include a web-based 3D model viewer.

This will be a 9 month project scheduled for completion in September 2016. We will be presenting results at the SimBuild 2016 Conference in Salt Lake City.