Developments in the Built Environment 7 (2021) 100054

Contents lists available at ScienceDirect

Developments in the Built Environment

journal homepage: www.editorialmanager.com/dibe/default.aspx

BuildingSync: A schema for commercial building energy audit

data exchange
Nicholas Long *, Katherine Fleming, Christopher CaraDonna, Cory Mosiman
National Renewable Energy Laboratory, Golden, CO, 80401, USA

A R T I C L E I N F O A B S T R A C T

Keywords: Numerous data formats exist to exchange building related information throughout a building's lifecycle; many are
Commercial building energy audits all-encompassing formats while some newer formats are focused on specific software data exchange between
Data modeling actors such as system to system, system to user, or user to user. Despite this, data format challenges occur during
Building data exchange
each iteration of a commercial building energy audit. To overcome these challenges, BuildingSync has been
BuildingSync
Building performance standards
designed to harmonize building data exchange during building energy audits. The schema was developed to be
interoperable to support various use cases such as reporting audits in an electronic format, tracking proposed,
implemented, and discarded energy conservation measures, and storing building characteristics (at multiple
levels) for audits, benchmarking, and building energy analysis. This article will review the commercial building
data exchange landscape, detail the development of BuildingSync, and provide examples of its use in the built
environment.

1. Introduction
Companies and utilities spent an average of $0.046 per kWh to save
energy in the United States between 2009 and 2013, as reported
(Hoffmanet al., 2015). This cost represents roughly 50% program
administration cost and 50% participant cost. The Energy Independence
and Security Act of 2007 (EISA) (United States Congress, 2007) requires
that 25% of covered federal facilities perform a comprehensive energy
and water evaluation each year, resulting in each facility being evaluated
every four years. The evaluation includes reporting the consumption of
electricity, natural gas, steam, and water and requires implementation of
energy conservation measures (ECMs) that are deemed cost-effective
(Henderson and Fowler, 2015). Within the United States, the total pri-
mary energy in the commercial building sector alone was estimated at
3.9 quadrillion BTUs (quads) in 2007 and 4.8 quads in 2019. For federal
facilities, the total primary energy was 1.1 quads in 2007 and 0.89 quads
in 2019 (U.S. Energy Information Administration, 2020). Even with an
increase in floor area over time, the energy savings are clear. Incentives
to reduce energy consumption are important, as are processes to mini-
mize the cost associated with the reduction.
EISA 2007 was an ambitious act, and many years later the tools
infrastructure and standards are finally catching up. ASHRAE released
updates to Standard 211 – Standard for Commercial Building Energy
Audits in 2018 (ASHRAE, 2018) and Standard 100 – Energy Efficiency in
Existing Buildings in 2018 (Friedmanet al., 2018). Both standards are
paramount in defining how to catalog building characteristics and energy
consumption in commercial buildings. Neither of these standards specify
the exact format for the data, although they do provide suggestions such
as ENERGY STAR Portfolio Manager (US Environmental Protection
Agency (EPA), 2020a) and BuildingSync (National Renewable Energy
Laboratory, 2020a).
Audit results are usually stored as PDFs or spreadsheets. However,
these formats have limited value for automated processing and interop-
erability. Data formatting is an important aspect of accurate and cost-
effective building evaluation because: 1) the characterization of the as-
sets, systems, and operational parameters of a building is a necessary
precursor to providing recommendations on how energy consumption
might be reduced; 2) the ability to reuse and analyze audit data from one
year to another (or four years later) can provide important insight on how
the building has changed; and 3) having data in an open, machine-
friendly format allows it to be used for and exchanged between various
use cases. BuildingSync, a schema designed to facilitate building data
exchange, was developed to address these challenges. This manuscript
discusses and evaluates existing schemas related to the building sector,
describes the requirements considered during BuildingSync schema
development as well as the principal elements of the schema, and

* Corresponding author.
E-mail address: nicholas.long@nrel.gov (N. Long).

https://doi.org/10.1016/j.dibe.2021.100054
Received 24 February 2021; Received in revised form 4 June 2021; Accepted 10 June 2021
Available online 18 June 2021
2666-1659/© 2021 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).
N. Long et al.
presents four BuildingSync implementation examples.
2. Background
Building data exchange is a broad term used to describe the transfer of
building data from one user to another. Users can be computer systems
(e.g., databases, spreadsheets, applications, etc.) or persons in the form of
software developers, building energy modelers, etc. For successful data
exchange, there needs to be an agreement on the definition of the terms
(expressivity) and the structure of the data (formalization) (Rebstock
et al., 2019), (Blobel, 2011). The lowest level of expressivity and
formulation is a list of terms in the form of a glossary or data dictionary.
The more expressive formats become schemas, taxonomies, and
ontologies.
Various dictionaries, schemas, ontologies, and taxonomies exist to
help characterize building attributes. The Building Energy Data Exchange
Specification (BEDES) is a data dictionary of building-related terms
(LBNL, 2018). BEDES is more formal and expressive than a list of terms
since BEDES has at least one level of definition, lists of enumerations, and
the ability to define composite terms. BEDES is used in software appli-
cations, standards, and other schemas to ensure that building terminol-
ogy is consistent (e.g., what is the meaning of gross floor area, or overall
window [term 1] U-factor [term 2]). UNIFORMAT II is another popular
data dictionary that was originally developed in 1993 and provides four
levels of abstraction (ASTM, 2020). The standard was developed jointly
by the United States General Service Administration and the American
Institute of Architects. Many schemas, data models, taxonomies, and
ontologies exist and will be discussed in the next section.
While characterization of buildings and their attributes is important,
the standardization of recommended building energy conservation
measures (ECMs) is equally important and has been lacking in the
building sector. Typically, the documentation of an ECM is completed by
an energy auditor or building energy modeler looking to describe an
upgrade to a building that can potentially save energy or water. EISA
2007 requires a list of ECMs to be reported to the agency's compliance
tracking software (CTS). For this purpose, the CTS has a set of predefined
ECMs that can be selected by the auditor during the evaluation. The list of
ECMs was created in part from ASHRAE Standard 100, which provides a
list of hundreds of ECMs in a simple data dictionary. The ability to define
new ECMs in a standardized method is active research and not a focus of
this manuscript.
2.1. Existing building schemas review
Numerous schemas have been developed to support the building
sector and new schemas are appearing every year. The existing schemas
are typically designed to facilitate the exchange of data between
industry-standard software applications and various databases. Prior to
the development of BuildingSync, several schemas were evaluated in
order to understand the capabilities and functionality of existing tools so
as to avoid redundant efforts (Hendron and Deru, 2015). Criteria for
evaluation included data format (such as type, usability,
machine-friendliness, existing software library support, and flexibility),
level of detail supported, as well as intended use cases and their
respective requirements. Although many existing schemas and tools are
well-adopted and valued by industry, there was an apparent lack of
support for the commercial building energy audit data exchange process
(at the time of authoring BuildingSync circa 2014).
The large majority of existing schemas utilizes the Extensible Markup
Language (XML), which has become widely adopted across multiple in-
dustries for facilitating data transfer (Andrulis and Thomas, 2012). A
review has identified several existing schemas that support the exchange
of data for critical building sector processes including Building Infor-
mation Modeling (BIM), Building Energy Modeling (BEM), residential
energy audits, and building operation performance. In total, 16 schemas
were evaluated. All the evaluated schemas were open source and
2
Developments in the Built Environment 7 (2021) 100054
currently in use. As seen in Fig. 1, the majority supported XML with JSON
being the second most common format.
We identified three criteria critical for the success of a commercial
building energy audit data exchange format: extensibility, support, and
use case applicability.
2.1.1. Extensibility
To maximize the usefulness of building characteristic data, schemas
must be extensible to allow additional inputs to be added and to
accommodate easy data exchange with other data sources and tools. This
requires a schema to be open source (or at a minimum must contain user
defined fields or be open platform) so that other authors can expand upon
it for their specific tools and applications. Because building characteristic
data involves an expansive and varying set of terms and definitions, it is
also critical for a schema's extensibility in this space to align with the
BEDES protocol for maximum compatibility amongst other data sources.
All the schemas reviewed in this effort were open source, as seen in
Fig. 6; however, the figure also shows that roughly half of the schemas
reviewed—including COMNET (COMNET, 2019), CBECC-COM (Cali-
fornia Energy Commission, 2013), and EnergyStar-XML (US Environ-
mental Protection Agency (EPA), 2020b)—do not follow the desired
BEDES specifications. This is in part because these schemas postdate the
development of BEDES. This potential misalignment of terms and defi-
nitions makes it more difficult to synchronize data between multiple
sources, which limits the usefulness of the data for interoperability and
consequently adoption of the schema. Others, including CityGML,
HPXML, and IFC (through IFCXML) (buildingSMART, 2018) were
determined to be extensible schemas for continued development in this
space for the right application. For example, HPXML provides a standard
data format that allows for a flexible and streamlined approach for
reporting and analysis, which minimizes time spent exchanging data
while maximizing the usefulness of the audit process (Department of
Energy, 2013). However, as discussed in the following sections, these
schemas may not be the best fit for extension into the commercial
building energy audit data collection.
2.1.2. Support
Productive development and useability of any schema requires that it
be adequately supported; this includes active development with funding,
industry adoption with relevant use cases, and an active user group.
Adequate support of a schema ensures developers and users that bugs
will be addressed and active community support will be available as well
as mitigates concerns that the schema could soon become obsolete.
Many of the existing schemas reviewed were found to be actively
supported. This includes CityGML (and its derivative, CityJSON),
HPXML, Green Building XML (gbXML), Brick (2020), Haystack (Prairie
et al., 2016), and Industry Foundation Class (IFC), which were also
determined to be extensible, therefore making them well-suited for
extended development for the right application and use case. However,
many of the others were not determined to be actively supported for
various reasons. Green Button (https://www.greenbuttondata.org), for
example, currently lacks substantive continued funding which limits the
reliability of additional external development. A full summary of schema
Fig. 1. Supported Data formats of common building data exchange schemas.
N. Long et al.
support can be found in Fig. 6.
Another dimension of support is related to the number of software
libraries available to interact with the format. JSON and XML are heavily
supported in multiple programming languages with libraries to read,
write, query, and in some cases generate code based on the schema. IFC
XML is part of IFC and is a viable candidate. Actual implementation
would best be done using IFC itself; however, the adoption of IFC in the
US is limited with most exchange used for transferring structural BIM
Data, not collecting data related to commercial building energy audits
(Singh, 2016).
IEP XML (IEP Project Team, 2015) is a schema designed to streamline
the process for consumers to explore and request efficiency and renew-
able projects, as well as service providers to market, bid, contract, and
manage projects. The core components of the model (set of XSDs) enable
definition of site and building information, energy systems, utility service
and energy consumption data, participants, and measures. This project
was closely aligned with some of BuildingSync's use cases; however, it is
no longer supported.
2.1.3. Use case applicability
Extending an existing schema to satisfy new use cases would gener-
ally be more beneficial than developing a new schema if there is sub-
stantial overlap of the use cases and intended user base. Adding
definitions and features or modifying the schema for interoperability
could save considerable development time for the overlapping sections.
There could also be an established user group ready to use the new
schema features, which would promote adoption compared to an entirely
new, unfamiliar schema. However, if the intended use cases do not
contain substantial overlap, extending an existing schema would have
little benefit over starting a new schema and could be more complicated
and constrained for developers and users.
The primary use case of BuildingSync is to store and exchange com-
mercial building data between multiple users and formats throughout a
building's lifecycle. This includes data transfer for general building
characteristics, multiple-level energy audits (including timeseries data),
Fig. 2. HPXML top level structure.
3
Developments in the Built Environment 7 (2021) 100054
and energy conservation measures (ECMs), all with flexible input re-
quirements. To further maximize the usefulness of the data, BuildingSync
use cases also include leveraging relevant data for the purposes of
building energy modeling (BEM) as well as facilitating automatic report
generation. Many existing schemas support some of these use cases, but
none were determined to be a close-enough match to justify expanding
an existing schema rather than developing a new one.
HPXML, for example, supports the energy audit data exchange for
residential buildings, including physical building characteristics, ECMs,
energy consumption with flexible timesteps, and project tracking details
(Andrulis and Thomas, 2012). However, HPXML does not support the
unique fields and definitions required for commercial buildings, and
expanding it to do so would be more complicated than starting anew.
Fig. 2 diagrams the top-level structure of the HPXML schema. The
top-level elements of an HPXML file collect data needed for home energy
performance projects such as building information, contractor perform-
ing the home inspection, customer (such as the homeowner), utility in-
formation, software provenance, and building consumption. The schema
then further defines the structure being analyzed within the Building
element. The focus of BuildingSync is to catalog information for com-
mercial buildings (such as commercial HVAC systems, elevators and es-
calators, cooling towers, etc.) causing a use case misalignment.
The Green Building XML (gbXML) schema facilitates the transfer of
design data from BIM software such as REVIT or AutoCad to a suitable
input format for BEM software such as OpenStudio (Green Building XML
Schema (gbXML), 2019), (Guglielmetti et al., 2011). The elements
defined by gbXML include useful information for energy audits by
capturing the original design intent of the building as specified in the BIM
model. However, these elements were found to exclude other critical
energy audit elements that are not generally found in BIM models such as
metered energy usage, ECM recommendations, and ASHRAE 211 audit
fields. While it would have been complicated to extend gbXML to be
aligned with the BuildingSync use cases, the gbXML namespace and el-
ements shown in Fig. 3 were imported into BuildingSync. Rather than
developing an entirely new structure, gbXML's wide adoption and direct
N. Long et al.
Fig. 3. GbXML space element structure.
usefulness were leveraged.
Some schemas such as BCF-XML (Paasiala et al., 2017) and BIMXML
(BIMXML, 2010), (Benelellam et al., 2014) are intended to transfer BIM
data, but not energy audit data. IFC (and IFCXML) handles both BIM data
and generates inputs to common BEM software, but has limited defini-
tions required for commercial building energy audits. Due to the exten-
sive differences between BIM data and commercial energy audit data,
extending a BIM schema to meet the intended use cases of BuildingSync
would not be intuitive for the developers or the resulting user base.
Additionally, BIM data would generally be transferred to the schema
through BIM software such as REVIT (Lee et al., 2015). Since energy
auditors primarily enter their data into clipboards and spreadsheets and
may not have access to or experience with BIM software, requiring the
use of BIM software for data transfer could severely limit the applicable
user base.
CityGML defines portions of commercial building energy audit data
but is not compatible with energy modeling software and was not found
to have flexibility with the level of detail of its inputs. Since version 2.0.0
of CityGML was released, multiple papers have discussed the limitations
of the LOD approach such as insufficient levels and proposed enhance-
ments (Biljecki et al., 2016), (Tang et al., 2018). The primary critique is
that LODs do not have strict informational requirements or means of
validation, making it difficult to ensure the necessary data is there for
different applications. Additionally, the primary intent of CityGML is to
model at the city level rather than at the building level (Gr€ oger et al.,
2012). This creates a level-of-detail mismatch that would lead to ineffi-
cient development efforts for an application well outside of its intended
use case. EDAPT XML (Longet al., 2013), CBECC-COM, and COMNET
include various features to handle energy modeling data exchange, but
lack the capabilities needed for commercial building energy audits.
The limitations of extensibility, lack of support, and limited use case
applicability would result in significant development efforts to extend an
existing schema and an inefficient process to meet the intended needs of
BuildingSync. For the two best aligned schemas, CityGML and IFC(XML),
it was determined that the inertia of these larger projects would slow
down the desired adoption rate of BuildingSync, especially within the
United States where IFC is still not as ubiquitous as it should be. In
addition, the focus of BuildingSync is a single commercial building and
4
Developments in the Built Environment 7 (2021) 100054
not an urban-based model. A summary of the characteristics of all
reviewed schemas can be seen in Fig. 6, Fig. 7, Fig. 8, and Fig. 9.
2.2. Characteristics of evaluated schemas
The 16 building schemas evaluated were categorized and character-
ized based on the primary and secondary intended use cases.
Schema function was varied, with the majority of primary function
split between building energy modeling, BIM, and Operations. The sec-
ondary function, when present, was either Energy Audit Data Exchange
or Building Energy Modeling, as shown in Fig. 4.
Note that a schema can have multiple use cases and an experienced
software developer can make use of data in a myriad of formats; however,
the schema typically is determined rigid by a developer for uses other
than the primary and secondary use cases. For example, if a schema is
primarily structured to store timeseries data, a building's designed wall
U-Value may still be stored in the schema, albeit in a non-ideal fashion.
Fig. 5 shows the characteristics of the supported data formats
including whether the schemas are open source, BEDES compliant, sup-
ported, and whether the inputs are constrained and/or extensible.
The following figures delve into the most common use cases identi-
fied in Fig. 4 to understand the level of detail of the various schemas
within each use case. The building energy modeling (BEM) use case for
building data exchange schemas is of interest as it covers about 20% of
either the primary or secondary schema use cases. Fig. 6 illustrates the
type of data collected for each BEM schema. As shown, there were five
subcategories of interest, including capturing energy modeling simula-
tion results, generating inputs to common energy modeling software,
accommodating ECMs, support for multi-tenant buildings, and facili-
tating report automation.
Building Information Modeling (BIM) was another popular use case
covering about 15% of either the primary or secondary schema use cases.
Fig. 7 shows the BIM use case intentions. The categories of interest
include accessing BIM data from common building energy modeling
software and converting BIM to BEM. BIM to BEM conversion has been a
long-time goal between architects and engineers, and the table below
shows that only a couple of schemas aim to fulfill this goal.
There were several schemas that fell within the energy audit data
exchange use case and are shown in Fig. 8. The subcategories for the
energy audit data exchange use case included which schemas focus on
residential or commercial buildings, which support ECMs, and which
support multi-tenant buildings. The figure shows that there were more
schemas focused either entirely or somewhat on residential buildings
than on commercial buildings. Three of the schemas covered the use of
ECMs in their use case intentions. CityGML covered all the intentions.
Finally, Fig. 9 shows the intentions for the building operation data
exchange use case. The intentions included characterization of building
management system (BMS) data, transfer of BMS data and utility data
exchange. Both Brick and Haystack were focused on characterizing BMS
data and are not intended for utility data exchange. Haystack was the
only schema reviewed intended for BMS data transfer.
3. BuildingSync development
The review of existing schemas showed first and foremost that there
were plenty of data formats available related to building data exchange.
Many of these formats did not stand the test of time and/or were
absorbed into larger efforts, e.g., aecXML (AEC Working Group, 2002)
was integrated into IFC. Of the schemas reviewed, only two had a pri-
mary focus on energy audit data; one of these is no longer being devel-
oped and the other is focused on residential buildings. Various schemas
could contain the data needed for commercial building energy audits;
however, extensions would need to be implemented to handle the
ASHRAE Standard 211 requirements such as tracking low-cost/no-cost
energy efficiency measures. It was determined that the best path for-
ward would be to create a new schema similar to HPXML for commercial
N. Long et al. Developments in the Built Environment 7 (2021) 100054

Fig. 4. Primary and secondary use cases of building data exchange schemas.

Fig. 5. Characteristics of common building data exchange schemas.

buildings that enables specific use cases as described in this section. and worked closely with the energy auditing industry to develop use
Hendron and Deru were early developers of the BuildingSync schema cases (Hendron and Deru, 2015). BuildingSync was developed in

5
N. Long et al. Developments in the Built Environment 7 (2021) 100054

Fig. 6. Building energy modeling use case intentions.

Fig. 7. Building information modeling use case intentions.

Fig. 8. Energy audit data exchange use case intentions.

Fig. 9. Building operation data exchange use case intentions.

6
N. Long et al. Developments in the Built Environment 7 (2021) 100054

coordination with subject matter experts to ensure that its development

was aligned with industry needs. The identified requirements for Buil-
dingSync are listed below:

● The process must be a bottom-up development effort that provides a

comprehensive representation of a commercial building.
● The process must focus on the data collected for commercial building
energy audits.
● The schema must be buildings focused and not centered around a
specific software development effort.
● The schema must be constrained but also extensible with user-defined
inputs
● The schema should support ASHRAE Standard 211 Level 1 to Level 3
Audits (ASHRAE, 2018)
● The schema should support ASHRAE Standard 100 (Friedmanet al.,
2018)
● The schema should support multi-tenant buildings
● The schema should support external data references
● The schema should support ECMs as well as association of ECMs to
different levels of the facility, site, building, subsection, thermal zone,
or space
● The schema should support reporting benchmarking and simulation
results
● The schema should support storing data as strings, doubles, booleans,
and floats
● The schema should support storing spatial data and time series data

BuildingSync was developed to address the need for a robust and

flexible language format that could seamlessly manage data from com-
mercial building energy audits in order to maximize the effectiveness of
the audit process (DeGraw et al., 2018). Furthermore, after the emer-
gence of BEDES, it was necessary to map the BEDES terms to a compre-
hensive schema to actually enable building data exchange. Formal
development of BuildingSync began in 2014. BuildingSync is currently
categorized as a data model with an XML Schema that is built using the
terms from a data dictionary (BEDES). The current version of Building-
Sync (Version 2.3) provides a versatile representation of a building. Later
versions of BuildingSync imported namespaces and schema elements
directly from gbXML in order to prevent redundant efforts.
The development of BuildingSync interacted with and affected
various other data tool developments. The main developments tracked
during the development of BuildingSync include BEDES, the Building-
Sync Use Case Selection Tool (National Renewable Energy Laboratory,
2020b), and DOE's Audit Template Tool (Pacific Northwest National
Laboratory, 2020). BEDES slightly predates the development of Buil-
dingSync and was used as the foundation for BuildingSync term selec-
tion. BuildingSync mapped 347 terms and 1134 enumerations from
BEDES, there are, however, terms in BuildingSync that are not yet in
BEDES. The BuildingSync Use Case Selection Tool is a
BuildingSync-adjacent tool developed to support BuildingSync users: it
includes the ability to visualize the schema without an XML viewer, the
ability to link BuildingSync elements with their BEDES terms, and the
ability to specify BuildingSync use cases. BuildingSync use cases are
structured Schematron (Van der Vlist, 2007) files that allow users to
specify which subset of BuildingSync elements (or pair of elements) are
required for a particular data exchange application (i.e., use case). An
example of a use case is an instance of BuildingSync that has only the
required fields for an ASHRAE Standard 211 Level 1 audit.
3.1. Principal schema elements
The root of the schema is the BuildingSync element. Fig. 10 shows the
structure of the root element which has only two sub-elements: Programs
and Facilities. The Programs element contains information about the
assessment program for which the data is collected. The Programs
element was added several years after the initial release to facilitate
Fig. 10. Top-level elements of the BuildingSync schema.
renaming the root element from Audit to BuildingSync. The removal of
Audit was done to encourage use cases other than commercial building
energy audits. This change required the addition of a new element
(Programs) to describe the primary use case of the BuildingSync file. The
Facilities element contains the bulk of the data being collected with
respect to the building being evaluated and is described in more detail
below.
Facility sub-elements include:

Tenants—general contact information about a facility's tenant(s)

Contacts—general information about a facility's contacts

Reports—information gathered during a particular audit—such as the
audit level, date, and utility data—or generated during an analysis. A
report can include results for multiple scenarios that were consid-
ered/simulated, such as the ECMs applied and resulting annual en-
ergy totals. Timeseries data can also be stored in a scenario.

Measures—information on the ECMs applied or considered, including
type of measure (i.e. add/remove/modify/replace), technology
category affected, and cost data.

Schedules—information on the facility's occupancy and equipment
schedule(s), such as start and end dates and times.

Systems—information about the systems and loads in the building(s),
such as HVAC, Lighting, Process Loads, etc.

Sites—information related to the site locations and ownerships as
well as the buildings they contain.
The schema can be customized to support specific use cases through
the use UserDefinedFields elements. These elements are made up of the
FieldName and FieldValue sub-elements and are used to store data custom
to a specific use case. Most complex schema sub-elements support the
UserDefinedFields element.

7
N. Long et al.
3.2. Energy conservation measures
Energy conservation measures (ECMs) are actions taken in the oper-
ation or equipment of a building that reduce energy usage while
enhancing safety, comfort, and functionality (Kelsey et al., 2018). Once
an energy audit is complete, a list of recommended ECMs will be pro-
vided based on the audit findings for the building owner's consideration.
In some cases, the ECM list includes items that are necessary per local
code requirements. ECMs are a critical portion of the energy audit pro-
cess as they enable the changes that cause energy use reduction; this
makes managing the data associated with ECMs an important aspect of
maximizing usefulness.
As mentioned earlier, other schemas such as HPXML and EDAPT XML
support ECMs; however, the inputs are freeform and allow users to input
any name. This leads to a lack of standardization which limits the use-
fulness and comparability of the data. BuildingSync avoids these pitfalls
by creating a standardized list of ECMs within the schema. This facilitates
simple aggregation and/or comparison between multiple buildings and
sites. The ECM list in the BuildingSync schema is based on the classified
Fig. 11. Technology categories of BuildingSync ECMs.
8
Developments in the Built Environment 7 (2021) 100054
ECM listings that are defined in ASHRAE Standard 100 (Friedmanet al.,
2018) as well as additions determined necessary by various stakeholders
including FEMP and the Audit Template Tool. The BuildingSync list of
ECMs and its resulting structure have been widely adopted for the pur-
pose of providing guidance for reducing energy usage in existing build-
ings. Adopting ECMs from ASHRAE Standard 100 aligns BuildingSync
with the terminology already being commonly used in industry.
The BuildingSync ECM section is expansive, supporting elements such
as capital cost, energy savings, and cost savings for each ECM. These are
necessary for assessing the cost-effectiveness and overall financial impact
of the different options recommended by the audit. This is helpful
because implementation likelihood is largely based on the financial
prospect. ECMs can also be grouped into packages in order to evaluate
the impact of several options bundled together (PackageOfMeasures
element). BuildingSync also supports ECM tracking details including
installation status, start date, and end date. These elements are designed
to provide adequate detail such that the data can be used to inform de-
cisions several years down the road. About half of all ECMs adopted as a
result of energy audits are likely to be implemented 1–6 years after the
N. Long et al.
audit is complete, so a system that maintains the usability of the data is
important (Taylor et al., 2016).
Fig. 11 shows the various technology categories that are used to
define the ECMs. Each technology category contains an enumerated list
of measures from which to select. For example, the ChillerPlantImprove-
ments category provides ECMs such as “Add or replace cooling tower” and
“Replace chiller”. If the nearly 200 predefined BuildingSync ECMs do not
cover the measure being defined, then there is a CustomMeasureName
field that can be used. It is highly recommended to avoid this field in
order to ensure data standardization.
In a typical commercial building energy audit, ECMs are generally
associated with a specific subset of a site. This is an important detail to
communicate as the costs and expected outcomes associated with
implementing an ECM will be highly dependent on the recommended
scope. BuildingSync was designed with the requirement to associate
ECMs to different levels of the facility, site, building, subsection, thermal
zone, or space. The BuildingSync LinkedPremises element provides an
effective way to establish which portion of the project an ECM applies to.
For example, a recommended insulation improvement might only apply
to one of the many buildings in an analysis, or a lighting retrofit might
only be intended for a specific space. The LinkedPremises element allows
users to specify these distinctions. Fig. 12 shows the structure of the
element in schema view. Each premises type (e.g., facility, site, etc.) can
define multiple linked IDs and within each linked ID, the ability to specify
the floor area (either as an absolute number or percentage) can be sup-
plied to handle the ASHRAE 211 requirement of specifying the per-
centage of floor area that an ECM applies to.
The LinkedPremises element is located throughout BuildingSync (not
just within the Measures element). For example, LinkedPremises exists
under the duct systems to specify which part of the premises that the duct
system is feeding.
3.3. Reporting
A key element of ASHRAE Standard 211 is its focus on reporting
(Section 6 of the standard). It specifically calls out exact informational
requirements that need to be reported by the energy auditor in order to
comply with the standard. Moreover, Annex C provides a normative
reporting spreadsheet that auditors are required to submit in order to
comply with the standard. For this reason, reporting is a key focus of the
BuildingSync schema. Each report is intended to capture the level of
audit performed, provide key information about contacts, utilities and
rate schedules, and other relevant financial parameters assumed for
Fig. 12. Linked premises in BuildingSync.
9
Developments in the Built Environment 7 (2021) 100054
calculations summarized in the report (escalation rates of different fuels,
discount factors, etc.).
The reports also capture information about multiple analysis sce-
narios for the premises (via the Scenario element). For example, a Level 1
audit requires energy performance information for benchmarking and
targets to be included. Additionally, auditors must capture energy con-
sumption information for the premises as it stands currently, while also
proposing measures (or packages of measures) be implemented and
capture the expected energy, water, and cost savings expected for that
scenario at different temporal scales (annual, monthly, etc.).
Each Scenario captures information about resources consumed (fuels
or water) via a set of ResourceUse child elements. The primary analysis
scenarios captured by BuildingSync are summarized in Table 1.
Summary elements are used to capture information about annual
consumption or demand characteristics for individual ResourceUses (i.e.
AnnualFuelUseNativeUnits or AnnualPeakNativeUnits) or in aggregate (i.e.
BuildingEnergyUse or SiteEnergyUseIntensity), while TimeSeries elements
are used to capture aggregate or peak measurements for resources at
temporal scales less than a year. TimeSeries elements used in the calcu-
lation of summary elements can be linked to that summary element (i.e.
AnnualFuelUseLinkedTimeSeriesIDs) to more accurately capture how that
summary metric was calculated.
Representing consumption of resources is critical to the consistent
reporting and analysis of audit data, particularly when analyzing
benchmarking and audit data at a city or national scale. Care has been
taken to define BuildingSync elements related to energy and water flows
based on ANSI/ASHRAE Standard 105 (Fig. 13), which is also the
approach adopted by Standard 211. The intent is that regardless of the
person performing the audit, the consistent reporting of energy con-
sumption data enables scalable analysis.
Table 1
Summary of the primary scenario types considered by BuildingSync.
Section Short Description Scenario Purpose
from 211
6.1.2 Current Building Exactly 1 Scenario to represent historical
Measured building data, fuel resources, and the monthly
and annual data values for the different
resources. This is defined by a Scenario typed as
the following:
Scenario/ScenarioType/CurrentBuilding/
CalculationMethod/Measured
6.1.3 Benchmark At least 1 Scenario to represent data from a
benchmark, declaring the type of benchmark
used (Building Performance Database, CBECS,
etc.) and the associated benchmark value. This is
defined by a Scenario typed as the following:
Scenario/ScenarioType/Benchmark
6.1.4 Target At least 1 Scenario to represent the target
building performance and estimate the expected
savings. This is defined by a Scenario typed as
the following:
Scenario/ScenarioType/Target
N/A Current Building Exactly 1 Scenario used to represent the current
Modeled building modeled performance. This is used as
the baseline for calculated energy/cost savings
as necessary for 6.1.5 and 6.1.6. This is defined
by a Scenario typed as the following:
Scenario/ScenarioType/CurrentBuilding/
CalculationMethod/Modeled
6.1.5 & Proposed More than one Scenarios to represent ECM
6.1.6 Building analysis, associated costs, savings, resources
used, and consumption. Each of these scenarios
can include  1 individual measure(s) to enable
different packages of measures to be considered
as well. Comparison to a baseline or other
scenario can be conveyed via the ReferenceCase
element. This is defined by a Scenario typed as
the following:
Scenario/ScenarioType/PackageOfMeasures
N. Long et al. Developments in the Built Environment 7 (2021) 100054

of details and its importance, (3) a commercial retrofit evaluation

application in San Francisco, and (4) the import/export functionality
within DOE's Audit Template Tool.

4.1. BuildingSync data modeling of HVAC systems

There are significant opportunities to reduce energy consumption

related to mechanical systems and their operations, which is primarily
why schemas related to building control system data and fault detection
and diagnostics (Haystack and Brick) have seen such interest. Therefore,
there is also a need to be able to consistently define and represent
different HVAC system topologies and attributes in BuildingSync, so that
audit data regarding mechanical systems becomes useful. While many
elements and components for systems exist, it is not immediately clear
how they should be used. For this reason, an effort to model a set of ten
commonly occurring HVAC systems is underway. The following system
types are included:
Fig. 13. Building energy and site energy flows (ASHRAE, 2014).

Packaged single zone heat pump (PSZ-HP)

Packaged single zone air handling unit with a gas heating coil and DX
3.4. Resources
cooling (PSZ-AC)

Designated outdoor air system with fan coil air-cooled chiller and
Several resources were created to help current BuildingSync de-
boiler
velopers and potential new adopters. The entire BuildingSync project

Variable air volume air handling unit with reheat
relies on open-source software and is publicly accessible mostly through

Variable air volume air handling unit with parallel fan-powered boxes
GitHub. A description and location of the resources are described below.

Variable air volume air handling unit, fed by a chiller with no reheat
and a zone heat pump

BuildingSync General Website, https://buildingsync.net

Water source heat pumps cooling tower with boiler

BuildingSync Schema, https://github.com/BuildingSync/schema –

Fan coil chiller with district hot water
The XSD version of the schema as well as the unit tests to ensure that

Window air conditioner with forced air furnace
additions to the schema do not break the test files and other depen-

Direct evaporative coolers with gas unit heaters
dent applications.

BuildingSync Use Case Selection Tool, https://buildingsync.net/v
Along with XML snippets for defining these systems, simple graphics
alidation – Online tool and API for validating instances of
are also being created. Fig. 14 provides an example for the PSZ-AC system
BuildingSync.
from the above list.

Transformations, https://github.com/BuildingSync/transformations
Each of the turquoise boxes represents a BuildingSync element.
– library of transformations for upgrading versions of BuildingSync.
Necessary relationships not captured via direct containment are shown
This repository leverages XLST to perform the transformations.
via an arrow with a relationship type annotated. The graphic can be

BuildingSync Use Cases, https://github.com/BuildingSync/use-cases
summarized as follows:
– List of BuildingSync example instances and Schematron files for
five different use cases.

A motor system is used to drive the fan system.

BuildingSync TestSuite, https://github.com/BuildingSync/TestSuite

The fan system is used by the delivery system to distribute air
– Python-based library to aid the development of use cases, specif-
necessary for heating and cooling
ically the Schematron files.

The delivery system has a cooling source which is direct expansion

BuildingSync Gem, https://github.com/BuildingSync/BuildingSyn
and a heating source which is a furnace
c-gem – Ruby gem designed to convert an ASHRAE Standard 211

This entire system is part of the building and is specifically linked to
Level 1 energy audit into an OpenStudio building energy model for
the retail section of the building.
simulation in EnergyPlus (Crawley et al., 2005). Example Building-
Sync files are included in the BuildingSync-gem-examples repository,
4.2. ASHRAE standard 211 and level of detail specification
https://github.com/BuildingSync/BuildingSync-gem-examples.

BSyncr, https://github.com/BuildingSync/bsyncr – A BuildingSync-
The need to specify the level of detail (LOD) was unrealized until
based wrapper around the normalized meter energy calculation that
BuildingSync was used for ASHRAE Standard 211. BuildingSync was
is implemented in R (NMECR).
designed with the need to cover all the fields defined in ASHRAE Stan-

BSyncPy, https://github.com/BuildingSync/bsyncpy – Python pack-
dard 211, but the ability to constrain the required elements based on the
age for reading and writing BuildingSync instances.
audit level (i.e., preliminary energy analysis, Level 1, Level 2, Level 3)
was not considered. In conjunction with the development of the Buil-
4. BuildingSync implementations
dingSync Use Case Selection Tool, the need to clearly define the levels of
detail within BuildingSync was required. BuildingSync uses four levels of
One of the lessons learned with regards to developing a standalone
detail that roughly align with the auditing level in ASHRAE Standard
schema is the need to provide users with tools to understand the schema
211. The levels are defined as LOD 000 to LOD 300. Fig. 15 graphically
such as comprehensive documentation with ample examples. Further-
represents how the LOD progressively adds detail to the defined building.
more, since BuildingSync was built with no specific software develop-
For example, in a LOD 000 the user is expected to only supply a handful
ment project in mind, once BuildingSync adopters expressed interest,
of fields about the building's location, use type, and rough areas; whereas
several changes were required to provide the requested functionality.
in a LOD 200 the user is expected to fill out a full inventory of the
This section describes four different BuildingSync-related projects, (1)
building assets. At LOD 300, the linking and placement of the building
data modeling of an HVAC system in BuildingSync, (2) definition of level
systems is required. Each LOD requirement is a use case instance in the

10
N. Long et al.
Fig. 14. Recommended implementation of a PSZ-AC system in BuildingSync.
BuildingSync Use Case Selection Tool and exists as a Schematron file.
4.3. The Bay Area Regional Energy Network Integrated Commercial
Retrofit project
The Bay Area Regional Energy Network Integrated Commercial
Retrofit (BRICR) project was initiated to create an analysis framework
using BuildingSync that would leverage the data gathered in energy
audits to automate the creation of building energy models in OpenStudio.
The original objective of BRICR was to conduct city-scale building energy
modeling for small and medium commercial buildings in order to target
ECM potential (DeGraw et al., 2018). This would require a streamlined
effort to 1) obtain building characteristic data for the city building stock,
2) use the data to generate energy models, and 3) store all of this data in
an accessible format for further analysis. The current BRICR workflow is
as follows (DeGraw et al., 2018), (Hooper et al., 2018):

Aggregated building records are converted into GeoJSON files using
CBES (Honget al., 2015) and CityBES (Hong et al., 2018) tools.

GeoJSON files are translated to BuildingSync format.

BuildingSync stores the data in the SEED Platform (Long et al., 2020).

BuildingSync accesses the data stored in SEED to produce OpenStudio
energy models for the building stock, including the baseline (existing
case) as well models for each ECM listed in the audit.
11
Developments in the Built Environment 7 (2021) 100054

The simulation results from OpenStudio are captured by BuildingSync
and stored in the SEED Platform (NRELLBNLDOE, 2020).

Results in the SEED platform are aggregated to evaluate energy sav-
ings and the resulting cost-effectiveness of the different ECMs.
Several components of this workflow offer value to the energy audit
industry. Most notably, the ability to translate BuildingSync files into
OpenStudio energy models provides a path for energy audit data to be
directly utilized to generate energy and cost savings results.
4.4. New York City local law 87 and the Audit Template tool
Since 2009, New York City has required periodic energy audits on a
subset of its commercial buildings as part of the Greener Greater Build-
ings Plan (DeGraw et al., 2018). Originally, the data acquired during
these audits was documented via the LL87 Energy Audit Data Collection
Tool. Although this method was straightforward, it had very little po-
tential beyond storing data in individual spreadsheets—an inefficient
task for any kind of large-scale analysis. Understanding these limitations,
New York City adopted a workflow that includes the Asset Score Tool,
Audit Template Tool (AT), and BuildingSync to maximize the usefulness
of this large set of energy audit data (DeGraw et al., 2018).
The Asset Score Tool was developed by Pacific Northwest National
Laboratory (PNNL) to create a simplified workflow for the generation of
N. Long et al.
Fig. 15. BuildingSync levels of detail.
OpenStudio building energy models (Wang et al., 2016). The tool in-
cludes definitions for key building characteristics such as geometry,
lighting, and mechanical. The simulated Energy Use Intensity (EUI) is
then used to score the building based on its annual energy performance.
Additionally, the Asset Score Tool performs simulations of multiple ECMs
in order to determine cost-effective upgrade options. The Audit Template
Tool (AT) (Pacific Northwest National Laboratory, 2020) was created as
an additional capability of the Asset Score Tool with the purpose of
providing a method for auditors to report the data from building energy
audits as required by mandatory ordinances and jurisdiction re-
quirements. This allows the audit data to be directly used for the creation
of building energy models and Asset Score rating.
BuildingSync was added to this workflow to streamline the flow of
12
Developments in the Built Environment 7 (2021) 100054
energy audit data by expanding AT's capabilities to both read and write
BuildingSync files. Once the data is converted to BuildingSync format, it
can be transferred to and from the SEED platform, as well as other
compatible tools. This allows both the audit data from AT and the energy
modeling results generated from Asset Score to be queried, analyzed, and
automated for portfolio-scale analysis.
AT has provided a path to write LL87 Energy Audit Data to the SEED
platform for storage, as well as to the Asset Score Tool where building
energy models can be automated and used to inform upgrade decisions.
Additionally, AT has been expanded to read and write BuildingSync files
which further allows this data to be queried and analyzed. For example,
18% of the uploads to Audit Template in August of 2020 were in Buil-
dingSync format and over 3500 BuildingSync files were exported and
N. Long et al.
reimported into an upgraded version of AT in late 2020 (National
Renewable Energy Laboratory, 2020c).
AT is not limited to NYC and has been leveraged in various other
cities. AT has the ability to define new templates to allow new cities,
states, or municipalities to select the required fields for their audit
program.
5. Conclusions and discussion
There exist many building data exchange schemas for transferring
data that support various use cases including urban analysis, BIM to BEM,
Building Energy Modeling, AEC Exchange Data, Utility Audit Exchange
Data, Energy Audit Exchange Data, Operations, and BIM. This paper
described how 16 commonly used schemas fit into these use cases and the
intentions of each use case. The evaluation of the existing schemas was
used to help define requirements for a newer schema called Building-
Sync. The BuildingSync schema was designed with the commercial
building energy audit exchange use case in mind. BuildingSync covers
several of the missing intentions within the energy auditing use case such
as being focused on commercial buildings, including ECMs, and handling
multi-tenant buildings.
The development of BuildingSync focused on defining the principal
elements such as premises element which includes the facilities, sites,
buildings, thermal zones, and spaces. Building systems are linked to the
premises through the LinkedPremises elements. One of the advantages of
BuildingSync is the ability to define ECMs in a structured format. Buil-
dingSync was developed as an XML Schema allowing for a large number
of existing software packages to easily access. Within BuildingSync,
transformations are handled using XSLT transformations which are easily
implemented in multiple software packages.
BuildingSync has been adopted by various software programs
including the two projects discussed in this article: BRICR and LL87.
These two projects have generated and successfully leverages thousands
of BuildingSync instances to exchange data between data tools such as
SEED and OpenStudio.
Four different implementations were described in detail and include
an example of modeling a PSZ-AC system in BuildingSync, defining level
of detail with respect to ASHRAE Standard 211, the use of BuildingSync
in the BRICR project, and the use of BuildingSync and PNNL's Audit
Template Tool for New York City's LL87.
One of the benefits of single XML files describing commercial build-
ings in a consistent manner is the access to machine learning and artifi-
cial intelligence. For example, if HVAC data is consistently defined in
BuildingSync across a whole portfolio, then running a distributed anal-
ysis to read these values and determine unforeseen relationships to other
elements within the BuildingSync file is easily accomplished. This
capability is true for other schemas as well; however, commercial
building energy audits rarely have consistency between audits and now
with thousands of audited buildings defined in BuildingSync this is more
easily accomplished.
6. Future work
Significant work has been undertaken since 2018 to revamp the usage
of BuildingSync, make it more comprehensive, and expand the validation
of BuildingSync documents for different use cases. Through our experi-
ence working with BuildingSync and via discussions with users, addi-
tional effort is necessary to make it more useable and to make
implementations more consistent.
One criticism often encountered is that onboarding new users and
applications with BuildingSync can be significantly difficult or time
intensive, which slows and limits adoption. Much of this has to do with
the schema size (~18,000 lines) as well as the diversity of information
that can be represented by the schema. Applications using BuildingSync
also have substantially different purposes. For example, some applica-
tions implement a preliminary energy analysis style audit of the building
13
Developments in the Built Environment 7 (2021) 100054
(very high-level building characteristics) along with granular timeseries
data to perform statistical analysis of consumption patterns and provide
preliminary recommendations for ECM implementation. Other applica-
tions are intended to expedite the capture of all information necessary for
a Standard 211 level 2 audit. In order to address this challenge, two
complementary efforts will be undertaken:
1. Modularization of BuildingSync: Modularizing the schema would
enable implementers to progressively onboard themselves. Instead of
having to initially digest the entirety of BuildingSync, users can start
with simple modules capturing the least detailed information. For
example, users may only wish to initially capture information about a
building's gross square footage and address. Then, as the sophisti-
cation of their application or their implementation of BuildingSync
grows, users can progressively implement more complex modules
that could capture different sections of the building, such as HVAC
systems, envelope constructions, etc.
2. Development of a BuildingSync Software Development Kit
(SDK): Authoring XML is not a familiar task to a large portion of the
software development community. While libraries exist to author
XML in the majority of programming languages, the process is tedious
(adding things one element at a time). This means that most appli-
cations wanting to incorporate storage, import, or export of Buil-
dingSync content must author their own library. Developing an SDK
would expedite the process of onboarding developers and integrating
BuildingSync into existing tools by centralizing the development
effort into a library for general use.
Levels of detail for ASHRAE Standard 211 preliminary analysis (Level
000), Level 1 (Level 100), and Level 2 (Level 200) audits have been well
defined and implemented via Schematron. However, additional efforts
need to be undertaken to define the informational requirements for more
specific levels of detail. This would include defining the purpose for the
new level of detail (i.e. able to fully replicate 3D geometries) as well as
what this entails for specific BuildingSync elements.
Additionally, more use cases (formalized as Schematron documents)
will hopefully be added by others in the BuildingSync community. Ap-
plications seeking to test data interoperability with one another could
specify the BuildingSync elements necessary for their applications via
their own Schematron use case document. Others in the community
could then validate their documents through the BuildingSync Use Case
Selection Tool API to understand conformance for individual documents.
Another use case planned for development is related to data re-
quirements for measurement and verification style analyses, such as
normalized metered energy consumption (NMEC). Developing this use
case would demonstrate the ability to capture information from audit to
measurement and verification of implemented measures using a single
technology.
A final planned effort for the next development cycle is to reduce the
number of user defined fields needed by specific applications (mainly the
Audit Template tool) to fully represent their data. This effort will
formalize the user defined fields as proper XML elements and embed
them in the proper locations within the schema.
Declaration of competing interest
The authors declare that they have no known competing financial
interests or personal relationships that could have appeared to influence
the work reported in this paper.
Acknowledgements
The authors would like to thank the efforts of many project team
members including Mark Borkum, Jason DeGraw, Michael Deru, Bob
Hendron, William Livingood, Kristin Field-Macumber, Barry Hooper,
Daniel Macumber, Marjorie Schott, Ted Summer, Alex Swindler, Austin
N. Long et al.
Viveiros, and Jie Xiong. The authors also wish to acknowledge Harry
Bergmann for his guidance and support of the research. This work was
authored by the National Renewable Energy Laboratory, operated by
Alliance for Sustainable Energy, LLC, for the U.S. Department of Energy
(DOE) under Contract No. DE-AC36-08GO28308. Funding provided by
the US Department of Energy Office of Energy Efficiency and Renewable
Energy Building Technologies Office. The views expressed herein do not
necessarily represent the views of the DOE or the US Government. The US
Government retains and the publisher, by accepting the article for pub-
lication, acknowledges that the US Government retains a nonexclusive,
paid-up, irrevocable, worldwide license to publish or reproduce the
published form of this work, or allow others to do so, for US Government
purposes.
References
Aec Working Group, 2002. aecXML Working Group - Architecture, Engineering, and
Construction. http://xml.coverpages.org/aecXML.html. (Accessed 15 May 2019).
Andrulis, R., Thomas, G., 2012. Transforming markets with data transfer standards. In:
ACEEE Summer Study on Energy Efficiency in Buildings. Accessed: Jun. 17, 2019.
[Online]. Available. http://www.hpxmlonline.com/wp-content/uploads/2016/09/
ACEEE-Proceedings-2012.pdf.
Ashrae, 2014. Standard Methods of Determining, Expressing, and Comparing Building
Energy Performance and Greenhouse Gas Emissions.
Ashrae, 2018. ANSI/ASHRAE/ACCA Standard 211-2018. Standard for Commercial
Building Energy Audits, Atlanta, GA.
Astm, 2020. E1557 - 09: standard Classification for building Elements and related sitework —
UNIFORMAT II, no. Reapproved 2020 1–54.
Benelellam, A., Tisi, M., R
ath, I., Izs
o, B., Kolovos, D.S., 2014. Towards an open set of real-
world benchmarks for model queries and transformations. CEUR Workshop Proc.
1206, 14–22.
Biljecki, F., Ledoux, H., Stoter, J., 2016. An improved LOD specification for 3D building
models. Comput. Environ. Urban Syst. 59, 25–37. https://doi.org/10.1016/
j.compenvurbsys.2016.04.005.
Bimxml, 2010. BIMXML - Building Information Model Extended Markup Language
[Online]. Available. http://bimxml.org/.
Blobel, B., 2011. Ontology driven health information systems architectures enable
pHealth for empowered patients. Int. J. Med. Inf. 80 (2), e17–e25. https://doi.org/
10.1016/j.ijmedinf.2010.10.004.
Brick, 2020. Understanding Brick - BrickSchema. https://brickschema.org/concepts/.
accessed Apr. 21, 2020.
buildingSMART, 2018. Industry Foundation Classes Version 4.1.0.0 [Online]. Available.
https://standards.buildingsmart.org/IFC/RELEASE/IFC4_1/FINAL/HTML/.
California Energy Commission, 2013. “CBECC-Com.” Sacramento. CA. Accessed: Sep. 01,
2020. [Online]. Available. https://sourceforge.net/projects/cbecc-com/.
COMNET, 2019. COMNET: Guidelines and Quality Standards for Building Energy
Modeling. COMNET. http://comnet.org/. accessed Nov. 21, 2019.
Crawley, D.B., Hand, J.W., Kummert, M., Griffith, B.T., 2005. Contrasting the Capabilities
of Building Energy Performance Simulation Programs - Full Report. https://doi.org/
10.1016/j.buildenv.2006.10.027.
DeGraw, J., Field-Macumber, K., Long, N., Goel, S., 2018. BuildingSync in Action:
Example Implementations. In: 2018 ACEEE Summer Study Energy Effic. Build.,
pp. 1–12 [Online]. Available: https://buildingsync.net/static/documents/DeGraw-A
CEEE-BuildingSync-in-Action.pdf.
Department of Energy, 2013. HPXML: A Standardized Home Performance Data Sharing
System.
Friedman, G., et al., 2018. ANSI/ASHRAE/IES Standard 100-2018: Energy Efficiency in
Existing Buildings. Atlanta, GA.
Green Building Xml Schema (gbXML), 2019. http://gbxml.org/About_GreenBuilding
XML_gbXML accessed Jul. 01, 2019.
Gr€oger, G., Kolbe, T.H., Nagel, C., H€afele, K.-H., 2012. OpenGIS City Geography Markup
Language (CityGML) Encoding Standard, Version 2.0.0. No. 12-019. OGC Doc, p. 344
[Online]. Available. https://portal.opengeospatial.org/files/?artifact_id¼47842.
Guglielmetti, R., Macumber, D., Long, N.L., 2011. OpenStudio: an open source integrated
analysis platform. In: Proceedings of Building Simulation 2011: 12th Conference of
14
Developments in the Built Environment 7 (2021) 100054
International Building Performance Simulation Association, pp. 1–9 [Online].
Available. https://www.nrel.gov/docs/fy12osti/51836.pdf.
Henderson, J.W., Fowler, K.M., 2015. Federal Metering Data Analysis Needs and Existing
Tools. Accessed: Mar. 22, 2019. [Online]. Available. https://www.pnnl.gov/main/p
ublications/external/technical_reports/PNNL-24191.pdf.
Hendron, R., Deru, M., 2015. “BuildingSync Implementation Guide Version 1.0.0,”
Golden. NREL [Online]. Available. https://buildingsync.net/documents/BuildingSyn
c.v1.0-legacy.Implementation.Guide.pdf.
Hoffman, I.M., et al., 2015. The Total Cost of Saving Electricity through Utility Customer-
Funded Energy Efficiency Programs: Estimates at the National, State, Sector and
Program Level. Berkeley, CA.
Hong, T., Chen, Y., Piette, M.A., Luo, X., 2018. Modeling city building stock for large-scale
energy efficiency improvements using CityBES. In: ACEEE Summer Study on Energy
Efficiency in Buildings.
Hong, T., et al., 2015. Commercial Building Energy Saver: an energy retrofit analysis
toolkit. Appl. Energy 159, 298–309. https://doi.org/10.1016/
j.apenergy.2015.09.002.
Hooper, B., et al., 2018. The BayREN integrated commercial retrofits (BRICR) Project : an
introduction and preliminary results overview of BRICR software tools and workflow.
In: 2018 ACEEE Summer Study on Energy Efficiency in Buildings. NREL, pp. 1–12
[Online]. Available. https://buildingsync.net/static/documents/Hooper-ACEEE-
BRICR.pdf.
Iep Project Team, 2015. Integrated energy project (IEP). Accessed: Jan. 15, 2021.
[Online]. Available. http://iepmodel.ning.com/.
LBNL, 2018. BEDES Online Dictionary. LBNL. https://bedes.lbl.gov/bedes-online.
accessed Jun. 11, 2018.
Lee, Y.C., Eastman, C.M., Lee, J.K., 2015. Validations for ensuring the interoperability of
data exchange of a building information model. Autom. ConStruct. 58, 176–195.
https://doi.org/10.1016/j.autcon.2015.07.010.
Long, N., Swindler, A., Bergmann, H., Reagon, A., Held, A., Longley, J., 2020.
Standardizing city benchmarking and reporting: use cases in consolidating building
data with SEED. In: 2020 ACEEE Summer Study on Energy Efficiency in Buildings.
Long, N.L., et al., 2013. “Leveraging OpenStudio's application programming interfaces. In:
Proceedings of BS 2013: 13th Conference of the International Building Performance
Simulation Association.
National Renewable Energy Laboratory, 2020a. “BuildingSync”. https://building
sync.net/. accessed Mar. 21, 2020.
National Renewable Energy Laboratory, 2020b. “BuildingSync Selection Tool”. Golden,
CO.
National Renewable Energy Laboratory, 2020c. BuildingSync Update Webinar. htt
ps://nrel-seed.s3.us-east-1.amazonaws.com/resources/2020-09-11%20-%20Buildin
gSync%20Update%20Presentation.pdf. accessed Sep. 11, 2020.
Nrel, Lbnl, Doe, 2020. Standard energy efficiency data (SEED) platform. Accessed: Feb.
26, 2020. [Online]. Available. https://github.com/SEED-platform/seed.
Paasiala, P., Laukala, J., Lifl€ander, L., Linhard, K., Pijnenburg, E., van Berlo, L., 2017.
“BCF-XML.” buildingSMART [Online]. Available. https://github.com/buildingSMAR
T/BCF-XML.
Pacific Northwest National Laboratory, 2020. Audit Template Tool [Online]. Available.
https://buildingenergyscore.energy.gov/.
Prairie, D., Petze, J., Petock, M., Mathan, K.G.S., 2016. Project-Haystack—A Caba White
Paper.
Rebstock, M., Fengel, J., Paulheim, H., 2019. Ontologies-Based Business Integration 53
(9).
Singh, S.K., 2016. Investigating the Current State of Industry Foundation Classes in the
Construction Industry. Texas A&M University.
Tang, L., Li, L., Ying, S., Lei, Y., 2018. A full level-of-detail specification for 3D building
models combining indoor and outdoor scenes. ISPRS Int. J. Geo-Inf. 7 (11) https://
doi.org/10.3390/ijgi7110419.
United States Congress, 2007. Energy Information and Security Act of 2007, p. 310.
U.S. Energy Information Administration, 2020. Annual Energy Review. Washington, DC.
U.S. Environmental Protection Agency (EPA), 2020a. Portfolio Manager [Online].
Available. https://www.energystar.gov/buildings/benchmark.
U.S. Environmental Protection Agency (EPA), 2020. ENERGY STAR XML [Online].
Available. https://www.energystar.gov/index.cfm?c¼third_party_certification.tpc_
xml_forms.
Van der Vlist, E., 2007. Schematron. O'Reilly Media, Inc.
Wang, N., Goel, S., Makhmalbaf, A., Long, N., Jan. 2016. Development of building energy
asset rating using stock modelling in the USA. J. Build. Perform. Simul. 1–15. https://
doi.org/10.1080/19401493.2015.1134668 vol. 0, no. 0.