BuildingSync is a schema developed by the National Renewable Energy Lab (NREL) that provides a standardized data format for describing the physical and operational characteristics of buildings specifically for the purpose of commercial energy audits. This schema can be exported and imported by many software tools that allow common information to be shared (ie – interoperability). For a list of use cases, click here.
The BuildingSync Schematron tool includes a set of rules that validate data against the BuildingSync schema, helping to ensure that data is consistent and accurate for any specific software tool. In this case, a Schematron file was created solely for validating BuildingSync into ASHRAE BEQ portal.
ASHRAE Building EQ is a web-based tool developed by the American Society of Heating, Refrigerating, and Air-Conditioning Engineers (ASHRAE) that helps building owners and operators evaluate the energy performance of their buildings. The tool allows users to compare their building’s energy use to similar type buildings in the same climate zone and identify areas where energy efficiency improvements can be made. Building EQ includes a set of energy performance metrics that can be used to track improvements over time.
Users can import BuildingSync files into existing ASHRAE Building EQ projects allowing them to pre-populate the project with common energy auditing data.
We at Carmelsoft often get asked the some questions over and over again about Green Building XML (gbXML) since we oversee this popular BIM/energy modeling schema. So, we typed some of these FAQs into the ChatGPT generative AI engine, and it surprisingly returned some accurate and easy-to-understand results for a relatively obscure topic such as gbXML and energy modeling. We edited it a bit for clarity and expanded on some of the definitions:
Question 1: What is the difference between the “shell geometry”, “planar geometry”, and “rectangular geometry” elements?
In gbXML (Green Building XML) format, the ShellGeometry, PlanarGeometry, and RectangularGeometry elements are used to define the geometry of building surfaces in a building model. Here’s what each element means:
ShellGeometry: This element defines a building surface as a closed, planar, and non-intersecting 3D geometry. It can be used to represent complex shapes such as curved walls, domes, or vaults. The ShellGeometry element is typically used for building envelopes, such as walls, roofs, and floors.
PlanarGeometry: This element defines a building surface as a flat, planar, and non-intersecting 3D geometry. It can be used to represent flat surfaces such as windows, doors, and glazing. The PlanarGeometry element is typically used for non-enveloping surfaces that have openings, such as windows or doors.
RectangularGeometry: This element defines a building surface as a rectangular, planar, and non-intersecting 3D geometry. It can be used to represent surfaces that are rectangular in shape, such as a simple flat wall. The RectangularGeometry element is typically used for simpler, regular building shapes.
In summary, the difference between these elements lies in the shape and complexity of the building surfaces they define. The ShellGeometry is used for complex and irregular shapes, PlanarGeometry is used for flat surfaces with openings, and RectangularGeometry is used for simple and regular shapes.
gbXML Viewer
In regards to the online gbXML Viewer (aka – Ladybug Tools Spider Viewer), the following elements are used:
Shell Geometry: ShellGeometry data appears to have been used in older vesrions of Spider gbXML Viewer (R2) to gather surface data, and it occasionally appears in other “sandbox” files. Still, it has not been exposed to the user regularly.
Planar Geometry: PlanarGeometry data is used to gather all the coordinates in all the PolyLoops in every Surface. This data is used to draw the surfaces and openings in the gbXML Viewer.
RectangularGeometry: A popup box displays:
All the attributes of the RectangularGeometry of the currently selected surface
All the attributes of the RectangularGeometry of all the openings in the currently selected surface
Question 2: What are the differences between gbXML and Industry Foundation Classes (IFCs)?
Industry Foundation Classes (IFC) and gbXML are both data exchange schemas used in the architecture, engineering, and construction industry to represent building information in a structured and machine-readable format. However, there are some differences between these two standards:
Object-Oriented vs. XML-based: IFC is an object-oriented data model based on the ISO 10303 standard (also known as STEP), while gbXML is an XML-based format. This means that IFC uses a set of pre-defined objects with specific properties and behaviors, while gbXML uses a set of XML elements to represent building information.
Level of Detail: IFC is designed to represent detailed information about building elements, including their geometric, spatial, and semantic properties, which makes it suitable for use in advanced building design and construction processes such as Building Information Modeling (BIM). On the other hand, gbXML is designed to represent simpler building information, such as building geometry and thermal properties, making it more suitable for energy modeling and analysis.
Industry Adoption: IFC is widely adopted by the AEC industry as an open standard for BIM data exchange, and is supported by most major software vendors. gbXML is also widely used, but is more limited in its scope and is primarily used for energy analysis and simulation.
In summary, IFC and gbXML are both schemas used in the AEC industry for building data exchange, but they differ in their data models, level of detail, and industry adoption. IFC is more comprehensive and suitable for advanced building design and construction processes, while gbXML is more focused on energy modeling and analysis.
Also, IFCs are an ISO standard while gbXML is more a consensus standard.
Question 3: What are second-level space boundaries as it relates to energy modeling?
In the context of building design and modeling, a 2nd level space boundary (also known as a secondary space boundary) refers to a virtual boundary that separates two adjacent spaces within a building. Specifically, it defines the boundary between a space and any other adjacent spaces that are not primary enclosed spaces (i.e., spaces that have a direct contact with the outdoors or are conditioned spaces, such as rooms or corridors).
The concept of a 2nd level space boundary is important for several reasons. First, it allows building designers and engineers to more accurately model the thermal performance of a building by accounting for the heat transfer between adjacent spaces that may not have direct exposure to the outdoors. Second, it helps to define the occupancy and use of different spaces within a building, which is important for code compliance and building operation.
In a building model, a 2nd level space boundary can be defined using various methods, such as by explicitly drawing the boundary in a building design software, or by defining a set of rules that define the relationship between different spaces based on their location, orientation, and other properties. The resulting building model can then be used for various purposes, such as energy simulation, code compliance analysis, and facility management.
In June of 2020, Carmel Software received a U.S. Department of Energy Small Business Innovation Research (SBIR) grant to develop a new software tool to help energy modelers and energy auditors better design and maintain energy efficient buildings. The details of that grant were detailed in a prior blog post. This blog post will detail the progress that we have made so far. First, we need to restate the problem that has become even more urgent since last year:
As part of its national infrastructure plan, the Biden Administration has set a goal to retrofit 2 million commercial and residential buildings over the next 4 years. Energy usage and energy auditing data for these buildings need to be stored in a consistent manner to help achieve this aggressive goal.
Simulating the energy usage of buildings using sophisticated software has become a key strategy in designing high performance buildings that can better meet the needs of society. Automated exchange of data between the architect’s software design tools and the energy consultant’s simulation software tools is an important part of the current and future building design process.
In the Phase I funding opportunity announcement (ie – request for proposal or “FOA”), the DOE’s Building Technology Office (BTO) was asking that bidders suggest new workflows for either BuildingSync or HPXML, which are schema “languages” that allow for the transfer of commercial and residential energy auditing information, respectively . Our proposal focused on BuildingSync XML since we are more focused on the commercial building market. Phase I of this proposal focused on the workflow that involves the U.S. Department of Energy’s Asset Score Audit Template to BuildingSync to the ASHRAE Building EQ benchmarking portal. Carmel Software successfully developed a beta of Schema Server that streamlines the flow of information from DOE’s Asset Score Audit Template into ASHRAE Building EQ. With the simple click of a button, the producing or consuming tool performs quick data checks, tests-case validations, and then transfers to the consuming tool (in this case, ASHRAE Building EQ). We also integrated a gbXML viewer and validator so that any accompanying gbXML file for the same building as the BuildingSync XML file could be validated and viewed (assuming it includes the building’s 3D geometry designed from a tool like Autodesk Revit). We also went a bit beyond the scope of the original proposal and added the following features based upon user feedback:
We incorporated building data from additional data sources, most importantly from Energy Star Portfolio Manager. We are now able to import monthly and yearly building utility data (for electricity, natural gas, and other fuel types). This data is used by ASHRAE Building EQ to calculate the Building EQ Score. We do this by integrating with the Energy Star PM API (application programming interface).
We talked with many energy auditors and all of them use Excel to tabulate data and create reports. We created an integration with Microsoft Office software including Word and Excel. This integration allows users to create customized Office templates with keycodes representing data types from the BuildingSync XML data schema. This, in turn, will populate these customized Office templates with actual data from the BuildingSync XML files. The benefit of this is it allows users to keep their custom reporting Excel templates and populate them with data imported by Schema Server.
When we presented the Phase I beta to our DOE program manager and other interested parties, they were quite pleased with the progress that we have made so far. Most importantly, we began validating the true purpose and use of this portal by talking with 50 stakeholders over a 6-month period. The following objectives were outlined in Phase I and were met (or will be met by the end of the Phase I time-period of May 31, 2021):
Objective 1: RPI identified 10+ candidate test cases by interviewing energy modeling practitioners and other related professionals to identify issues with the current building asset data to consuming software tool workflow.
Objective 2: Selected the seven (7) or so most important test cases.
Objective 3: Developed the Schema Server web portal that included the functionality described above.
Objective 4: Developed an application programming interface (API) that allows third-party software developers to integrate with the Schema. This currently only works with Audit Template and Building EQ but will be expanded during Phase II.
We developed Schema Server (https://www.schemaserver.com) which incorporates many of the objectives listed above. This website allows users to create an account, add projects, import BuildingSync XML schemas from Audit Template, validate those schemas, export to ASHRAE Building EQ. It even allows you to store multiple versions of the BuildingSync XML file so it simulates a sort of version control software.
Let’s look at some of the functionality of this website. You are able to create a free account that allows you to begin entering as many projects as you want. A “project” is usually a building.
You can enter the following information about a building including basic demographic information:
We’ll discuss the Energy Star options later. At the bottom of this page is the “Schema Version List”. This is a list of all of the schema file uploads for this particular project. Think of it as almost a version control list similar to GitHub where it includes a list of all of the changes made on one or more files. This Schema Version List is a list of all of the changes that you have made to a schema file (either Building Sync XML or gbXML or others in the future).
As the user adds new schemas to the list, the version number automatically increases. When the user clicks one of the rows, it directs the user to a new web page that appears as follows:
Clicking the Validate button performs validation on the BuildingSync file using what is called Schematron. Schematron is used for business rules validation, general validation, quality control, and quality assurance that is that allows users to develop software-specific validation modules. The SchemaServer Schematron produces a report listing mandatory fields that are missing and a list of generic errors in relation to the imported BuildingSync file. The screenshot below shows an example of this:
The View button takes the user to a new webpage that allows the user to view the XML file in different ways:
I’ve been studying blockchain via an online Udacity course. It’s nothing short of revolutionary. When people say blockchain, most people think of Bitcoin, the popular cryptocurrency that has real value. However, blockchain is more than just cryptocurrency. It’s an entire platform that allows users to develop all new software tools not even remotely related to what exists today. I hope that this blog posting gives you a basic understanding of what exactly blockchain is and how it can be applied to industries such as Heating, Ventilation, and Air-Conditioning (HVAC) and the built environment.
Think of the blockchain as a type of shared database that differs from a typical database in the way that it stores information: typical databases are usually hosted on a company’s server (or user’s cloud account) and is managed and owned by that user. Blockchains store data in blocks that are then linked together via cryptography, and they are 100% public. Most importantly, they can be downloaded by anyone (which I’ve done to my computer). The Bitcoin blockchain stores every single Bitcoin transaction ever completed since 2009. Amazingly, all the user information associated with the Bitcoin transaction stored on the blockchain is anonymous, so they cannot be traced back to individual users (most of the time).
Here’s a good (but busy) graphic that shows an entire Bitcoin transaction on the blockchain:
Another way to look at blockchain is that it is a back-linked, decentralized and distributed-database of encrypted records. Let me simplify this definition a bit:
It’s a data structure where each block is linked to another block in a time-stamped chronological order
It’s an append-only transactional database, not a replacement to the conventional databases
Every node keeps a copy of all the transactions happened in the past which are secured cryptographically. Hence, almost impossible to hack.
All information once stored on the ledger is verifiable and auditable but not editable
Highly fault tolerant as there is no single-point-of-failure
Decentralized blockchains are immutable, which means that the data entered is irreversible and cannot be changed
Ethereum
While the blockchain for Bitcoin solely keeps track of every single Bitcoin transaction that has ever occurred since 2009, there are many other blockchains that focus on other domains. One popular example is Ethereum. Ethereum is a cryptocurrency with real value like Bitcoin. However, it is also a blockchain “virtual machine” that runs “smart contracts”. Smart contracts are simple software programs hosted by the Ethereum blockchain that can perform any number of functions. These simple software programs are programmed in a software language called “Solidity”. A good analogy to smart contracts is the Internet and websites. The Ethereum blockchain is the “Internet” and smart contracts are “websites” that are enabled by the Internet.
The Ethereum blockchain has millions of transactions. These transactions are grouped into “blocks.” A block contains a series of transactions, and each block is chained together with its previous block. Think of it as an encrypted linked list. That’s why it is called “blockchain”.
To cause a transition from one state to the next, a transaction must be valid. For a transaction to be considered valid, it must go through a validation process known as mining. Mining is when a group of nodes, or computers, create a block of valid transactions.
For a block to be added to the Ethereum blockchain, the miner must prove that it is faster than other competitor miners. The process of validating each block by having a miner provide a mathematical proof is known as a “proof of work.”
Any node on the network that is a miner can attempt to create and validate a block. Many miners from around the world try to create and validate blocks at the same time. Each miner provides a mathematical proof when submitting a block to the blockchain, and this proof acts as a guarantee: if the proof exists, the block must be valid.
A miner who validates a new block is rewarded for doing this work. Therefore, it costs Ether (or cryptocurrency) any time a new transaction is created on the Ethereum blockchain. The name of this compensation is called “gas”. Gas is the unit used to measure the fees required for a transaction. Gas price is the amount of Ether you are willing to spend on every unit of gas. It is measured in “Wei.” “Wei” is the smallest unit of Ether, where 1⁰¹⁸ Wei represents 1 Ether.
Ethereum blockchain is also cryptographically secure with a shared state. This means the following:
Cryptographically securemeans that the creation of digital currency is secured by complex mathematical algorithms that are very hard to break.
Shared-state means that the state stored on the blockchain is shared and open to everyone.
Smart contracts provide the following benefits:
Transparency: Allows users to have more confidence in goods purchased. It forces companies to make decisions that favor the consumer.
Traceability: Follows where it came from
Efficiency: Automates some types of transactions and handles back and forth that companies may normally go through. Also, give companies access to a shared database to help verify accuracy of records.
As I mentioned before, what’s unique about Ethereum is that it allows for smart contracts. These are software programs (written in a software language called Solidity) committed to the blockchain where the code and conditions in the contract are publicly available on the ledger. When an event outlined in the contract is triggered, like an expiration date, the code executes. The great thing about the blockchain is that every transaction gets updated on every node that hosts the blockchain, so it keeps everyone involved with the contract accountable for their actions. It takes away bad behavior by making every action taken visible to the entire network.
So, what are use cases for blockchain above and beyond just developing a website to perform that same functionality? The most obvious use case is cryptocurrencies: allowing anyone to download the entire blockchain and view all cryptocurrency transactions.
However, there are many other use cases other than those dealing with cryptocurrencies: basically, anything that requires public validation and exposure, like real estate transactions, intellectual property, voting, supply chain, and associated societal transactions.
Let’s look at a supply chain example: coffee production. There are many actors and actions that take place in the lifecycle of coffee production and consumption. The following image is a unified model language (UML) diagram that illustrates the actors and actions that take place.
Example of 4 actors in a coffee supply chain are:
Farmer: The Farmer can harvest coffee beans, process coffee beans, pack coffee palettes, add coffee palettes, ship coffee palettes, and track authenticity.
Distributor: The Distributor can buy coffee palettes and track authenticity.
Retailer: The Retailer can receive coffee palettes and track authenticity.
Consumer: The Consumer can buy coffee palettes and track authenticity.
Below is a UML sequence diagram that shows the actions between the various stakeholders:
The blockchain is a good mechanism to keep track of the life cycle of the coffee bean, especially for those consumers that want to know where it was sourced from and what the journey was all the way to their cup of coffee.
Solidity
Below is a screenshot of the solidity code in Visual Studio Code that helps keep track of the entire coffee bean life cycle.
The above screen shot shows blockchain source code written in the Solidity programming language specific to developing Ethereum smart contracts. It is an object-oriented, high-level language for implementing smart contracts. It is influenced by C++, Python and JavaScript, and is designed to target the Ethereum Virtual Machine (EVM). Solidity is statically typed, supports inheritance, libraries and complex user-defined types, among other features.
Solidity also focuses a lot on security (for obvious reasons). Because the blockchain is “public”, security is of the utmost importance. Solidity has unique ways to enforce security that differ from other software development languages. For example, directly in the declaration of a function, you can place what are called “modifiers” which are basically inline validators that either allow or disallow the function call based on who is calling the function.
Non-Fungible Tokens (NFTs)
There’s been a lot of talk about non-fungible tokens (NFTs). Non-fungible tokens or NFTs are cryptographic assets on a blockchain with unique identification codes and metadata that distinguish them from each other. They cannot be traded or exchanged at equivalency. This differs from fungible tokens like Bitcoin and Ethereum, which are identical to one other and, therefore, can be used as a medium for commercial transactions.
Basically, NFTs are a way to make digital assets like images, videos, and documents unique using the blockchain. A good real-world example is to compare it to the Mona Lisa painting in the Louvre. There’s only one Mona Lisa painting in the world, and it’s priceless. However, there are many reprints that anyone can buy. The same applies to digital assets. If an artist creates a beautiful JPEG image, they could technically email it to someone then that person could email it to all their friends and now everyone has a copy of that JPEG. However, NTFs allow an artist to ensure that the JPEG painting they created is unique and can then sell it. Even though copies of it could be made, there’s only 1 original that has true value.
Much of the current market for NFTs is centered around collectibles, such as digital artwork, sports cards, and rarities. One example of a use case is to mint NFTs that represent real estate deeds. The NFT would exist on the blockchain while the real estate deed would exist on a file service such as IPFS (inter-planetary file service) which is a shared-file service where encrypted files can be stored.
Interplanetary File Service
Like any widely used service, tokens are now based upon standards. NFTs evolved from the ERC-721 standard. Fungible tokens are based on the ERC-20 smart contract. ERC-721 defines the minimum interface – ownership details, security, and metadata – required for exchange and distribution of gaming tokens.
Applicability to HVAC
The question for this audience is: how can the HVAC industry take advantage of the blockchain to solve existing problems and pain points?
As I mentioned above, the blockchain is good for anything that is appropriate for public accountability. One important HVAC-related topic that is ripe for public accountability is the whole issue around the phase-down of high-GWP (Global Warming Potential) refrigerants (CFCs, HCFCs, and HFCs). EPA regulations under Title VI of the Clean Air Act (CAA) are designed to protect the environment and to provide for a smooth transition away from ozone-depleting refrigerants (ODRs).
EPA regulations under Section 608 of the Clean Air Act include record keeping and reporting requirements that are specific to different professionals or companies involved with stationary refrigeration and air-conditioning equipment. Technicians must keep a copy of their proof of certification at their place of business. Technicians servicing appliances that contain 50 or more pounds of ozone-depleting refrigerant must provide the owner with an invoice that indicates the amount of refrigerant added to the appliance. The records primarily include: location and date of recovery, type of refrigerant recovered, monthly totals of the amounts recovered, and amounts sent for reclamation.
This record keeping is a perfect application for the blockchain. It keeps all stakeholders accountable and also provides interested parties with a verifiable source of information about ozone depleting refrigerant evacuation.
Owners or operators of appliances that contain 50 or more pounds of ODRs must keep servicing records documenting the date and type of service, as well as the quantity of refrigerant added. Owners or operators must also maintain records of leak inspections and tests performed to verify repairs of leaking appliances.
The EPA will also be requiring third-party auditing of business’ HFC record keeping. This will provide transparency of HFC production and consumption data for the general public to view. Stay tuned for more updates on this subject.
Definitions
Like any industry, blockchain has its own expansive vernacular of software and related tool names. Here is just a brief list:
Smart contract: A “smart contract” is simply a software program that runs on the Ethereum blockchain. It’s a collection of code, functions and data that resides at a specific address on the Ethereum blockchain.
DApp: DApp stands for “decentralized application”. It is a piece of software that runs on a distributed or cloud network, rather than on a single dedicated server (like a desktop software program). By distributing the processing power and storage space across many devices, DApps are decentralized, making them more resistant to attack as there is no single point of failure that can be undermined. By their very nature, blockchain smart contracts are DApps.
Truffle: This is a software development environment and a set of software libraries that aid in the development of distributed apps on the Ethereum blockchain. (https://trufflesuite.com/ )
Ganache: This is a local test blockchain desktop (or command-line) application that can be installed on any user’s Windows or MacBook computer. It simulates the actual Ethereum blockchain and allows users to easily test their solidity apps locally on their computer without worrying about the network and consensus delays of the real or testnet Ethereum blockchain. It is an open-source project that is available on GitHub.
Solidity: Solidity is an object-oriented programming language for writing smart contracts. It is used for implementing smart contracts on various blockchain platforms, most notably, Ethereum.
Metamask: This is a cryptocurrency “wallet” and blockchain gateway that is a plugin to a user’s Internet browser. It allows anyone that owns Bitcoin, Ethereum, or another other cryptocurrency to interact with distributed applications that require cryptocurrency. In addition, users can load “test” Ether to test Dapps on the testnets such as Rinkeby and Kopstein. (https://metamask.io/ )
Rinkeby and Kopstein: Rinkeby and Kopstein are Ethereum test networks that allow for blockchain development testing before deployment on the actual Mainnet that costs real money (Ether). (https://rinkeby.etherscan.io/ )
Etherscan: Etherscan is the Ethereum blockchain explorer. It’s basically a search engine for all things Ethereum. It allows users to type in a block hash, a transaction hash, or account id to find out more information about those items. In addition users can search for Ethereum tokens and much more.
Remix: Remix is a web-based integrated development environment that allows users to develop Solidity code, compile it, deploy it to any of local or test Ethereum networks, then interact with the contracts once they are deployed. It’s a great tool for testing and debugging smart contracts and provides a quick user interface so users can input parameters that are sent to the blockchain.
Infura: Infura is a website that is also a web-service API that helps distributed apps connect with the Ethereum blockchain. Infura allows users to connect to the Ethereum blockchain without running a full node. It’s a lightweight alternative to downloading the entire blockchain to a user’s local computer. It makes the connection that allows users to take advantage of the functionality provided by web3.
Web3.js: This is a collection of libraries that allow users to interact with local or remote Ethereum blockchain networks. In other words, it allows developers to create web-based toools that interact with the blockchain.
zkSNARKS: This is a funny-sounding word that is an acronym that stands for: zero-knowledge succinct non-interactive argument of knowledge. That’s quite a mouthful but it’s simply a comprehensive method of data encryption that allows one party to prove it possesses certain information without revealing that information. It involves complex mathematical equations to accomplish this encryption. It is often used on non-fungible tokens (NFTs).
Ethstats: This is a website that keeps track of the status of the Ethereum blockchain and includes tons of statistics on all things Ethereum including latest block #, when the last block was added and much more:
In June of 2020, Carmel Software received a U.S. Department of Energy Small Business Innovation Research (SBIR) grant to develop a new software tool to help energy modelers and energy auditors better design and maintain energy efficient buildings. The details of that grant were detailed in a prior blog post. This blog post will detail the progress that we have made so far. First, we need to restate the problem that has become even more urgent since last year:
As part of its national infrastructure plan, the Biden Administration has set a goal to retrofit 2 million commercial and residential buildings over the next 4 years. Energy usage and energy auditing data for these buildings need to be stored in a consistent manner to help achieve this aggressive goal.
Simulating the energy usage of buildings using sophisticated software has become a key strategy in designing high performance buildings that can better meet the needs of society. Automated exchange of data between the architect’s software design tools and the energy consultant’s simulation software tools is an important part of the current and future building design process.
Steady progress over the past two (2) decades has led to computers having a pervasive impact on the building design industry. Building Information Modeling (BIM) and advances in building energy modeling (BEM) software have resulted in their adoption into the mainstream design process. BIM authoring tools are being adopted by more architects and engineers as these tools improve and become faster and easier to use. The whole premise behind BIM is that it is essentially a “database” where all the building information, including the geometry, is stored.
However, there is a fundamental disconnect between many of the BIM, BEM, building analysis, building asset, and building auditing software tools. Because these tools are developed by 10s, if not 100s, of different software vendors throughout the world, many of these tools do not “talk” with one another despite the fact they many of them require the same information about a building: i.e. – building square footages, wall areas, window areas, occupant densities, plug loads, occupancy schedules, and much more. There are many software tools in the building design, analysis, and auditing industry that allow engineers, architects, and energy modelers to perform the following types of analysis, including whole building energy use, heating and cooling load analysis, lighting analysis, CFD analysis, solar/shading analysis, life-cycle cost analysis, energy benchmarking, energy auditing, and more.
The fact that many of these tools do not talk with one another discourages wide use of these software tools by energy modelers and other related practitioners. This is where “interoperability” comes into play. Interoperability allows for the sharing of data between different software tools developed by many different vendors. Interoperability is essential for BIM to realize its potential as a transforming technology as opposed to 3D CAD programs that are limited in their use as holistic building design tools. In addition to BIM and BEM software, interoperability applies to additional software tools related to building asset information, building audit information, and energy benchmarking. This is where schemas such as gbXML, HPXML, BuildingSync XML, IFCs (Industry Foundation Classes) and others become quite relevant. For example, BuildingSync is a schema developed by the National Renewable Energy Lab (NREL) that allows for the exchange of building energy audit information such as energy efficiency measures, utility data, and building rating information. This information can be used by other types of software tools including energy benchmarking software (such as ASHRAE Building EQ (https://buildingeq.ashrae.org ), energy auditing software such as buildee, and custom software developed by cities and municipalities to satisfy energy auditing rules and mandates. Another example is Green Building XML (gbXML) which is the “language of buildings”. It was developed to facilitate the transfer of building information stored in CAD-based building information models, enabling interoperability between disparate building design and engineering analysis software tools. It is currently supported by over 55 software tools worldwide.
While interoperability schemas have been around for twenty (20) years and are integrated into all major BIM and building performance software tools, end-users still struggle with inefficient and ineffective workflows. For example, geometric information from one BIM authoring tool is not properly represented in a popular HVAC load calculation software tool developed by a third-party vendor. While users can always manually edit and tweak data in an XML file (fortunately, it is clear text) so that it successfully imports into a consuming software tool, the ideal interoperable workflow should not include any type of human intervention. In fact, the ideal workflow would comprise of seamless data transfers between software tools with a simple press of a button. While this may be a utopian vision, there is no reason why the current state-of-the-art cannot be dramatically improved.
In the original Phase I funding opportunity announcement (FOA), DOE’s Building Technologies Office (BTO) requested that research and development be conducted for innovative delivery models for increasing access to building asset data from tools such as Home Energy Score and Asset Score (https://buildingenergyscore.energy.gov/). For Asset Score’s Audit Template tool, one of the ways to increase access to this data by third-party software tools is using an interoperability schema such as NREL’s BuildingSync XML.
BTO asked that bidders suggest new workflows for either BuildingSync or HPXML. Our proposal focused on BuildingSync XML since we wish to target the commercial building space. We suggested developing a comprehensive web-based portal (or Software as a Service, SAAS) that would help facilitate the adoption of BuildingSync and other similar interoperability schemas by third-party building analysis, auditing, and benchmarking software tools. In our 20 years of experience developing and managing the popular Green Building XML (gbXML) schema, we have come to realize that schemas do not work for end users unless there is some type of “transport” mechanism and validator modeler that ensures successful importation into a consuming tool in a straightforward and efficient manner.
As part of Phase I of the FOA, Carmel Software developed a prototype of the SAAS described above, called Schema Server. This tool can import a BuildingSync XML file from any source (including U.S. Department of Energy’s Asset Score Audit Template), perform basic validation using Schematron technology. Additionally, this tool can import additional data for the same building from Energy Star Portfolio Manager and then send it over to a consuming software tool such as ASHRAE Building EQ to receive a building energy benchmarking score. Building EQ assists in the preparation of an ASHRAE Level 1 commercial energy audit (as defined by ASHRAE Standard 211) to identify means to improve a building’s energy performance including low-cost, no-cost energy efficiency measures and an indoor environmental quality survey with recorded measurements to provide additional information to assess a building’s performance.
Also, as part of Phase I of the FOA, we conducted a lot of market research. The reason we were able to do this is we were accepted to DOE’s Energy I-Corps program, a key initiative of the Office of Technology Transitions. This program pairs teams of researchers with industry mentors for an intensive two-month training where the researchers define technology value propositions, conduct customer discovery interviews, and develop viable market pathways for their technologies. Researchers return to the lab with a framework for industry engagement to guide future research and inform a culture of market awareness within the labs. In this way, Energy I-Corps is ensuring our investment in the national labs is maintaining and strengthening U.S. competitiveness long-term.
We found the Energy I-Corps training to be very valuable. It taught us some great concepts such as the Business Model Canvas, the Ecosystem Model, Timeline, Lean Startup Method, and other great concepts. In addition, and most importantly, it held us accountable to conduct 30 interviews within a 6-week period. In fact, we ended up conducting 60 interviews over a 6 month period. As we got better at interviewing, we were able to really target the right stakeholders and get the exact type of information we needed to develop a better software tool.
We recently developed a proposal for Phase II of this FOA that will add much more functionality based upon our interviews with industry stakeholders. The critical need we are focusing on is getting energy auditing and performance data from one software tool to another so that stakeholders are able to do the work accurately and quickly and make better decisions for building energy design and retrofits. For Phase I, we focused on just one workflow for our prototype: Transferring building energy auditing data from Asset Score Audit Template to the ASHRAE Building EQ benchmarking software discussed above. After interviewing the 60 potential stakeholders discussed above, we determined that the above workflow does not satisfy an overwhelming need for most users. However, this software platform (Schema Server) that we created in Phase I will be the basis for Phase II development.
For Phase II, we will be expanding the number of software tools that Schema Server currently focuses on. We will also be combining disparate data about the same building from multiple sources: 3D geometric data about a building may reside in a popular BIM authoring tool while historical electrical utility data may reside in Energy Star Portfolio Manager and energy auditing data may reside in Asset Score Audit Template. There are many other features we will be incorporating that will be discussed in future blogs.
This blog post has nothing to do with HVAC software, nor sustainable design software, nor, as a matter of fact, any type of software the Carmel develops. However, I felt the need to write this post since it deals with reducing greenhouse gas emissions, which is what our software is all about.
In fact, our software is all about helping engineers, architects, and technicians design more energy efficient buildings. Also, Carmel oversees the Green Building XML (gbXML) schema that allows disparate software tools in the building design space to communicate with one another, all in the name of designing more energy efficient buildings.
I truly hope our software is doing its part to help reduce our greenhouse gas emissions that are adversely affecting our planet in so many ways. I’ve lived in California for 20+ years, but only during the past 3 years have the wildfires consistently affected our way of life. I’ve always been wary of whether man truly affects our environment, but now that I am seeing it and experiencing it first-hand, I now believe it, hands-down. I have personally witnessed a marked and extreme effect of climate change: wildfires quite literally in my backyard and air so unbreathable that I need to wear N95 masks outside when on a run or bike ride. This has consistently happened over the past 3 late-summers/falls and prior to 2017, this NEVER happened. Something is seriously wrong.
Living in California, I am seeing more and more how man is altering our environment for the worse. Paradise, California has burned twice in the past two years. If that isn’t a message, I don’t know what else is.
That being said, I’ve decided to do my small part in reducing greenhouse gas emissions by biking to work 2 days/week. I am lucky enough to live within 10 miles of my office and also to live in a part of the country where the weather is fairly predictable during the spring and summer. Therefore, I am able to consistently bike to work each week.
Being a degreed professional mechanical engineer and software designer, I’d like to focus on the metrics of biking each day: how much I’m biking, calories I’m expending, gas I’m saving, and greenhouse gas emissions I’m reducing. However, before I delve into the metrics of biking, I’d like to talk about the more intangible benefits and features.
First of all, I truly love biking. There’s something about it that is so visceral for me. If I lived in the 1800s in the American Wild West, I probably would have loved riding horses. In fact, there are similarities between bicycling and riding horses: being thoroughly engulfed in nature, the wind, the natural means of speed beyond human capabilities. I often visualize my long bike rides during the week, anticipating them with increased urgency. In fact, I’ll admit, I’m a bit crazy when it comes to bicycling. I’ll get up at 4:30 am on Sunday mornings and bike 55 miles in 40 degree weather. I’m the only one on the road in West Marin County at that time. The comedian/actor Robin Williams (an avid biker who owned 50+ bikes) once said: “My favorite thing to do is ride a bicycle. I ride road bikes. And for me, it’s mobile meditation.” I can relate.
When it comes to biking to work, even after biking only 8 or so miles, I feel great. Yes, I am sweaty and need to change my shirt and apply deodorant, but I am energized and awake. Compare this to driving, I often have to fight to stay awake while drive just 8 miles to work. And when I do arrive to work, I am sometimes lethargic. I am NEVER lethargic when biking to work.
Another intangible benefit is that I’m super hungry and thirsty at the end of the day after biking just 16 miles to and from work. Food always tastes so much better on a hungry stomach.
Now, let’s talk metrics: I LOVE metrics and both the Garmin mobile app (I own a Garmin watch) and the Strava website provide tons of data and metrics.
Garmin Venu GPS Watch
My average time to work from home is about 40 minutes (compared with 15 minutes by car). The timing varies by 5+ minutes depending upon if I catch traffic lights and light-rail intersections. Also, other variables such as outside air temperature and wind speed affect my time: the colder it is (and the higher the wind speed, obviously), the slower I bike (often by 5 to 10 minutes).
The exact instance to work is 7.68 miles. The elevation is 500 ft. My average speed is 12 mph. There are a number of traffic lights on the way to work (5 to be exact). Also, there is a light-rail crossing which often causes a 5 minute delay. The following is a screenshot of one of my rides to work:
There’s a nice gradual elevation that runs parallel to Highway 101 (located in Marin County, CA, just north of San Francisco) that runs for about 1 mile or so. Following that elevation, the rest of the ride to work is either downhill or at an even elevation.
Calories burned are about 300 according to app. Realistically, I think calories burned are about 250 (I am 6’1″ and weigh around 155). Anecdotally, I’ve calculated that for each mile I bike, I burn around 35 calories (this is an average since some miles are downhill and others can be brutally uphill). Since I am also a runner, I calculated that every 3 miles of biking is equivalent to 1 mile of running in terms of calories burned (ie – 100 calories / mile of running).
Therefore, by bicycling to work, I am doing the following:
Riding 35 miles/week to work versus driving. This saves around 1.5 gallons of gas per week or 75 gallons of gas per year. While this is equivalent to only around $300/yr savings (I spend more than that on bike maintenance, new tires, and new brakes/year), if just 1,000,000 people (0.3% of the US population) nationwide did this, then we are talking 75,000,000 gallons of savings per year.
I’m reducing mileage on my car to the tune of 1,800 miles/year, which does translate into reduced wear and tear on my car and tires. This equates to an additional $500 in savings in terms of wear and tear. Also, due to COVID-19, car insurance companies are reducing premiums for less miles driven since so many people are working from home.
In terms of carbon reduction, I’m reducing CO2 emissions by 0.61 metric tons/year.
What about health benefits? I’m lucky to already be in good shape and at a good weight for my height. However, given the fact that over 30% of the US is obese, what if every American biked an average of 15 miles to and from work 2x per week, how much weight loss are we talking? As I mentioned above, the average calories burned are around 500 calories/ride back and forth. Since a pound of weight is equal to 3600 calories, it takes around around 7 back/forth rides to reduce 1 pound (assuming you do not eat more to offset the calories burned). Assuming you ride 2x/week, this translates into about 1 lb/month or 12 lbs/year. For someone who is 50 lbs overweight, this translates into a relatively easy way to lose that weight over a 4 year period (yes, I admit it’s not a fast way to lose the weight, but it’s a slow/consistent way to lose it and keep it off forever). Most weight-loss programs cannot claim this.
Other observations while riding a bike:
When in a car, it’s so easy to become disconnected from your surroundings and environment. You’re in a climate controlled environment with windows closed often listening to music or talk radio. However, when riding a bike, you are inherently immersed in the surrounding environment. It’s so much easier to observe the environment, both good and bad.
The bad:
Trash: I’m appalled by how much litter is on the sides of downtown roads and highways. It boggles my mind that people would throw trash outside their car instead of waiting to get home to place it in garbage bin.
Homelessness: While it’s hard to avoid seeing the homelessness while in a car; when on a bike, you feel the proximity even more so. Plus, you can hear their ramblings. It makes one realize how sad a situation homelessness is and how hopeless these people feel.
The good:
I feel I really get to know the town I live in by bicycling through it. It gives me a renewed appreciation for it and helps me feel more connected to it.
Parking is NEVER A problem. I can stop at the bank downtown without worrying about finding and paying for parking.
Most importantly, biking ALWAYS feels like an adventure to me. There’s constantly challenges and encounters that make it so engaging and interesting. Even picking up my wife’s prescriptions from the pharmacy feels like a fun adventure. Go figure.
To the contrary, driving does not feel like an adventure. In fact, it feels like a necessary burden. I always have a dreadful feeling driving due to bad traffic expectations, backups through downtown, lack of parking, etc. There’s NEVER a traffic backup when you are biking.
I recently bought a 2nd bike. My commute bike is on a 3-year old Trek FX 6 Sport hybrid, which has been great for commuting. My new bike is a Trek Domane TR 7 high-performance road-bike. What an engineering marvel: electronic shifting, incredible performance, hydraulic brakes, and so much more. Anecdotally, I compared my time over a 5 mile route on my hybrid vs. my new road-bike: a 6 minute improvement over my hybrid for every 5 miles. It really pays to have the right tools.
In summary, I wish I could convince more people to bike to work. It’s hard, I know, but Mother Earth is revolting against the excesses of 8 billion+ human beings: wildfires in CA and the Amazon, the most powerful hurricanes in recorded history, world-wide droughts, a Northwest Passage free of ice for the first time in human history. Look at the 2 pictures below. Need I say more?
Barrow Strait (Northwest Passage) in 1994 – Lots of iceBarrow Strait (Northwest Passage) in 2007 – No ice
