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
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 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.
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.
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.
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.
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.
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?
Carmel Software has recently received funding from the U.S. Department of Energy’s Building Technology Office (BTO) to develop a software tool that helps disparate software tools in the building energy audit space to communicate with one another, all in the name of reducing building energy usage. Remember, buildings use 40% of all energy in the United States, so this is a HUGE problem to solve.
The BTO released a Funding Opportunity Announcement (FOA), or a request for proposal in government-speak, to expand the number of third-party software tools that can import data from DOE’s Asset Score Audit Template (https://buildingenergyscore.energy.gov/ ) and the accompanying data format that it supports: BuildingSync XML (https://buildingsync.net/ ).
First, what is a building energy audit? The purpose of an energy audit is to determine where, when, why and how energy is used in a facility, and to identify opportunities to improve efficiency. Energy auditing services are offered by energy services companies, energy consultants and engineering firms. The energy auditor leads the audit process but works closely with building owners, staff and other key participants throughout to ensure accuracy of data collection and appropriateness of energy efficiency recommendation. The audit typically begins with a review of historical and current utility data and benchmarking of the building’s energy use against similar buildings. This sets the stage for an onsite inspection of the physical building. The main outcome of an energy audit is a list of recommended energy efficiency measures (EEMs), their associated energy savings potential, and an assessment of whether EEM installation costs are a good financial investment.
There are 3 levels of energy audits according to ASHRAE:
Level I: Site Assessment or Preliminary Audits identify no-cost and low-cost energy saving opportunities, and a general view of potential capital improvements. Activities include an assessment of energy bills and a brief site inspection of your building. Level II: Energy Survey and Engineering Analysis Audits identify no-cost and low-cost opportunities, and also provide EEM recommendations in line with your financial plans and potential capital-intensive energy savings opportunities. Level II audits include an in-depth analysis of energy costs, energy usage and building characteristics and a more refined survey of how energy is used in your building. Level III: Detailed Analysis of Capital-Intensive Modification Audits (sometimes referred to as an “investment grade” audit) provide solid recommendations and financial analysis for major capital investments. In addition to Level I and Level II activities, Level III audits include monitoring, data collection and engineering analysis.
Software Tools We are Working With
Let me explain what some of the tools we are working with:
Asset Score is a national standardized web-based software tool that can be used to assess the physical and structural energy efficiency and identify retrofit potentials of commercial buildings using whole-building simulation. The Audit Template tool is a subset of Asset Score and is used to create a standard building energy audit report and submit to selected jurisdictions to comply with local ordinances, such as New York City’s LL87 or San Francisco’s BRICK.
BuildingSync® is a common XML schema for energy audit data that can be utilized by different software and databases involved in the energy audit process. It allows data to be more easily aggregated, compared, and exchanged between different databases and software tools. This streamlines the energy audit process, improving the value of the data, minimizing duplication of effort for subsequent audits, and facilitating achievement of greater energy efficiency. BuildingSync can be exported from Audit Template so all information in an Audit Template project can be used externally by another software tool.
BuildingSync was developed to address the lack of an industry-standard collection format for energy audit data. Standardizing energy audit data can help energy auditors, software providers, building owners, utilities, and other entities by maximizing the value that can be obtained from each set of data – value obtained through collaboration, comparison, and reuse.
ASHRAE Building EQ (see blog post here about ASHRAE Building EQ) is a web-based portal that provides a quick energy analysis that benchmarks a building’s energy performance. Building EQ assists in the preparation of an ASHRAE Level 1 Energy Audit to identify means to improve a building’s energy performance including low-cost, no-cost energy efficiency measures and an Indoor Environmental Quality (IEQ) survey with recorded measurements to provide additional information to assess a building’s performance.
The Problem and Solution
Currently, the number of software tools that import Asset Score Audit Template data and BuildingSync is limited. The whole purpose of Asset Score Audit Template is to store energy efficiency data about a commercial building. However, this data is useless if it cannot easily be consumed by other related software tools that can perform building energy benchmark tests, building energy modeling, and other types of building analysis. The term used to describe how one software tool communicates with another is: interoperability.
Unfortunately, developing interoperability integration tools in existing building analysis software is a tedious and time-consuming process. Therefore, it discourages software developers from creating functionality such as those that import BuildingSync.
For Phase I of this DOE SBIR project, we proposed developing a web-based software tool (called Schema Server) that will completely streamline the flow of information from Asset Score Audit Template into third-party software tools such as ASHRAE Building EQ, so that all the user has to do is press one button on the producing or consuming software tool, and the software will perform quick data checks and validation and then seamlessly transfer data to the consuming tool, thereby eliminating the user having to manual enter the data. Phase I will focus solely on the workflow from Asset Score Audit Template to ASHRAE Building EQ. Once it is proven that this workflow can be streamlined, future phases will focus on other software tools. Phase I will also focus on making it easier for a third-party software developer to program BuildingSync import functionality into their building analysis software tool.
Designing energy efficient buildings is of utmost importance today due to a wide variety of factors including limited fossil fuel resources, pollution, global climate change, federal and state laws, high energy costs, and a host of other reasons. Buildings use 40% of all energy and a whopping 75% of electricity. If society is going to rely less on fossil fuels, we need to design more energy efficient buildings for both new and existing construction. The first step in designing more energy efficient buildings occurs during the initial design phase which involves running building energy simulation and analysis software that will predict yearly building energy usage. Improving the interoperability workflows discussed above will benefit the following stakeholders:
Energy modelers: Give them more incentive to use various software tools to design energy efficient buildings since it will be an easier and more seamless process to enter the same data in more than one BIM authoring and building analysis or benchmarking software tool.
Software developers: Gives them more incentive to integrate interoperability functionality into their tools if there is an easier and less expensive way to do it.
Building owners: By designing more energy efficient buildings, it will save building owners a significant amount of money in utility and energy costs over the lifetime of the building.
Society as a whole: Whatever people’s political beliefs, there is no arguing that our fossil fuel supplies are finite, we are polluting the earth, and adverse climate changes are occurring all over the world including in our own backyard of California with unprecedented wildfires. Designing energy efficient buildings is just one step toward reducing our reliance of fossil fuels and cleaning the air for future generations.
ASHRAE’s Building EQ Web Portal provides a quick energy analysis that benchmarks a building’s energy performance. Building EQ assists in the preparation of an ASHRAE Level 1 Energy Audit to identify means to improve a building’s energy performance including low-cost, no-cost energy efficiency measures and an Indoor Environmental Quality (IEQ) survey with recorded measurements to provide additional information to assess a building’s performance.
Two different evaluations can be used independently to compare a candidate building to other similar buildings in the same climate zone or together for an assessment of a building’s design potential compared to actual operation:
In Operation compares actual building energy use based on metered energy information.
As Designed compares potential energy use based on the building’s physical characteristics and systems with standardized energy use simulation.
The Old Way
When Building EQ was first introduced, building owners and engineers could submit information about their candidate building to ASHRAE using an Excel spreadsheet template. This was a very inefficient way of doing things. It involved filling out the required data into a spreadsheet, and then uploading the spreadsheet(s) to the ASHRAE Building EQ website. Then, ASHRAE personnel would open the spreadsheet and determine whether the data was valid, and if it was, what rating to assign the building. The spreadsheet method was wrought with many inefficiencies including:
If data was missing or invalid, the spreadsheet would be sent back to the building owner to be corrected. This involved working with multiple versions of the spreadsheet which could very quickly become confusing and could potentially result in working with outdated and incorrect data.
ASHRAE personnel would validate all of the data manually, which was a slow and inaccurate process.
There were no links within the spreadsheet to ENERGY STAR Portfolio Manager that would allow users to migrate data to/from other programs into bEQ.
The spreadsheet was only in IP units.
Many more inefficiencies too numerous to list here
The New Web Portal
In 2016, Carmel Software was hired to develop the web-based user interface that would solve all of the problems above and introduce even more efficiencies and features that a spreadsheet could never provide. In addition, Carmel has tasked to develop a website that would be able to accommodate many types of connected devices including Windows and Mac desktops/laptops, all iOS and Android mobile smartphones and tablets. After about 9 months of development, the ASHRAE Building EQ portal was officially launched, and it has been a resounding success. More project submissions were made within the first 2 months of the website launch than within the first 5 years of existence of the Building EQ rating system with only spreadsheet submissions. As of November 2019, over 500 projects have been submitted.
What Does Building EQ Measure?
The Building EQ rating system rates building energy usage only. It is not meant to compete with LEED which measures far more including water usage, material sourcing, and much more. The Building EQ rating system works as follows:
Based upon the building type, climate zone, and heating and cooling degree days, a lookup for a benchmark value is performed using an ASHRAE Standard 100 site median table derived from CBECS (Commercial Building Energy Consumption Survey) 2012 building energy usage data. This usage data is expressed in units of energy use intensity (EUI) which is the amount of energy used per square foot per year.
The user then enters a year’s worth of utility data and the total square footage of the building to calculate the specific building’s EUI. This building-specific EUI is compared with the normalized benchmark EUI and a Building EQ score is derived by dividing the two numbers then multiplying by 100. The range of the score is from 0 to 200 where 0 is the most energy efficient and 200 is the least. A score below 100 is considered energy efficient since the specific building beats the benchmark EUI derived from CBECS.
There are many additional inputs in the ASHRAE Building EQ web portal above and beyond those that are used to calculate the Building EQ score. Below is a list of these additional inputs for the In Operation method:
Building Performance Credentials
The “Building Performance Credentials” section allows the user to input any other ratings or scores the building may have received including Energy Star, LEED, Green Globes, and more.
The “Indoor Environmental Quality Screening” tab includes a number of accordions (sections) that allow the user to input additional information about the building.
The objective of the building indoor environmental quality (IEQ) screening is to verify that the IEQ of the building as it affects the occupants has not been obviously compromised in the pursuit of energy efficiency and energy savings. The screening is intended to go beyond professional judgment with the inclusion of actual measurements. The measurements are focused on areas identified in the screening and are therefore representative of the building spaces and not intended to be all inclusive. If no issues are identified, the Assessor should take representative spot measurements throughout the building in order to provide feedback to the building owner/operator. Representative space types may be determined by space type (office, conference room, corridor), by space usage (different tenants or floors), or by space system type (building served by multiple system types). The information is provided to the building operator for follow-up actions and to benchmark, evaluate, and diagnosis building systems that affect indoor environmental quality including thermal comfort, lighting quality, and ventilation for indoor air quality. The IEQ screening is not intended to serve in the place of a full IEQ evaluation performed by an expert in that field. For this reason, it is important that the building owner follow up separately on any deficiency or potential problem noted on the forms by having a full IEQ evaluation performed by a qualified professional.
Energy Efficiency Measures (EEMs)
This tab allows the user to input any energy efficiency or conservation measures that have been implemented. The measures are divided by category: Building Envelope, Lighting, HVAC, Refrigeration, Energy Generation/Distribution, Other). Within each accordion is a drop down with a list of pre-populated measures. These measures are outlined in Informative Annex D and Informative Annex E of ASHRAE Standard 100-2015. The measures are divided by category: Building Envelope, Lighting, HVAC, Refrigeration, Energy Generation/Distribution, Other).
The user is also able to enter a cost range and payback period for each measure.
There are 3 additional inputs in each accordion that allow the user to input their own custom measure descriptions along with cost ranges and payback periods.
Photos and Attachments
This final tab allows users to add photos and attachments along with descriptions and categories. These photos will appear in the narrative report.
Building EQ Reporting
Standard 211 Audit Spreadsheet
Building EQ does something else that no other rating system does: It works closely with ASHRAE Standard 211 – Standard for Commercial Building Energy Audits. This is an ANSI standard that formalizes the process of performing building energy audits. ASHRAE Standard 211 protects a building owner/operator’s energy audit investment by providing an outline for auditors and offering best practices that ensure quality audits. It sets forth requirements for the experience and credentials of energy auditors, specifications for compliance and clear definitions of the audit processes and scope.
A Standard 211 audit spreadsheet is included along with the actual text of the standard. This spreadsheet allows users to fill in all information related to Level 1 and Level 2 energy audits.
Remember, the primary function of an energy audit is to identify all of the energy streams in a facility in order to balance total energy input with energy use. The ASHRAE Level 1 is a simple and quick audit that requires a brief review of building operating characteristics. It mainly identifies low-cost/no-cost measures and will only uncover major problem areas. Level 1 audits are a great way to prioritize energy efficiency projects and to assess the need for a more detailed audit. The ASHRAE Level 2 audit includes the Level 1 audit plus more detailed energy calculations and life cycle cost analysis of proposed energy efficiency measures. This type of audit identifies all energy conservation measures appropriate for the facility given its operating parameters.
Much of the information required to fill out the Level 1 inputs in the audit spreadsheet are already inputted into the ASHRAE Building EQ web portal. Therefore, the portal allows the user (for a fee) to create a Standard 211 spreadsheet with many of the Level 1 inputs pre-populated. Even though the spreadsheet also includes Level 2 parameters, Building EQ does not include most of the information required for Level 2 audits. Therefore, this information needs to be manually filled in.
Below is a screenshot of one of the tabs in the Standard 211 Excel spreadsheet:
ASHRAE Building EQ Label
Once a Building EQ project is approved by ASHRAE personnel, the user is able to print out a Building EQ label that includes the Building EQ logo along with a sliding scale showing the final Building EQ score. The following is an example of the Building EQ label:
Building EQ Energy Audit Narrative Report
This Microsoft Word doc report provides a template for an ASHRAE Level 1 Energy Audit that follows the information in Section 6 (Reporting), Annex C (Reporting Forms), and Annex D (Report Outlines) in ASHRAE Standard 211. The template provides recommended text and boiler plate language to assist the user in preparing a comprehensive report and is automatically populated with information collected and entered into the Building EQ Portal as part of the Building EQ In Operation assessment process. The recommended text can be edited as needed by the user. The audit specific information populated from the Building EQ Portal is shown in filled-in tables in the report. Below is an example of two pages of the report:
The Building EQ portal includes additional functionality that helps expand its usefulness:
Integration with Energy Star EUI Data
Depending upon the building type that the user selects, the energy utilization index (EUI) data will either be pulled from ASHRAE Standard 100 database in Building EQ or from an Energy Star service hosted by Architecture 2030 Zero-Tool. Each Energy Star building type has a different set of parameters associated with it so the user will be prompted to input many different types of values. Once the user has inputted all of the required information, pressing the “Get EUI Values” button calls a remote calculation engine that retrieves the appropriate Energy Star EUI value based upon the building type and parameter inputs.
Integration with Energy Star Portfolio Manager
For electricity, natural gas, and other “non-delivered” fuel types, the user can import utility data that already exists in Energy Star’s Portfolio Manager software. All the user needs to do is export the utility data from a PM project to a .csv file. Then, import the .csv file into the appropriate fuel type. The data should be monthly for one year taken within the past 18 months.
Integration with BuildingSync
BuildingSync® is a common schema for energy audit data that can be utilized by different software and databases involved in the energy audit process. It allows data to be more easily aggregated, compared, and exchanged between different databases and software tools. This streamlines the energy audit process, improving the value of the data, minimizing duplication of effort for subsequent audits, and facilitating achievement of greater energy efficiency.
Several tools utilize BuildingSync including U.S. Department of Energy’s Building Energy Asset Score. Asset Score is a national standardized tool for assessing the physical and structural energy efficiency of commercial and multifamily residential buildings. The Asset Score generates a simple energy efficiency rating that enables comparison among buildings, and identifies opportunities to invest in energy efficiency upgrades. Data exported from Asset Score (specifically Audit Template) via BuildingSync can be imported into BuildingEQ to populate relevant (but not all) data.
The following are the latest stats as of December 1, 2019:
Carmel Software was hired by the National Renewable Energy Lab (NREL) to update and improve the Green Building XML (http://www.gbXML.org) schema, all in the name of improving interoperability amongst disparate building design software tools. This progress report summarizes the work completed over the past year.
Overall Goal and Objectives
The goal of this project was to validate the National Renewable Energy Lab’s (NREL’s) OpenStudio software tool to produce valid gbXML and also set the stage to validate other BIM and building analysis software tools in the future. There were three main objectives of this validation work.
The first objective was to demonstrate that the OpenStudio software could pass the gbXML validation procedure.
The second objective was to encourage other software vendors to certify their software using the validation procedure as well.
The third objective was to work towards a generic validator that could be used on general user models, as opposed to the strict test case models required by the gbXML validation procedure. Delivering a fully working validator was out of scope of this work, therefore requirements were developed to set the stage for future work.
In support of the first objective, we developed OpenStudio models which represented the buildings in the validation procedure test case. These models were generated programmatically using the OpenStudio Ruby Application Programming Interface (API) to reduce maintenance costs and to allow them to be leveraged for other purposes. OpenStudio passed the validation procedures and is now the first software authoring tool to officially become “gbXML certified” (http://gbxml.org/OpenStudioCertification_Latest ).
In support of the second objective, we drastically improved the validation website, documentation, and tools required to apply the validation procedure. We publicized the validation procedure and encouraged gbXML software vendors to apply it to their tools. This required contacting other gbXML software vendors directly as well as making public announcements, conducting live webinars, and promoting other ways to generate user interest in the validation efforts. We publicized the state of the OpenStudio validation efforts to encourage other software tools to apply the validation procedure to their own tools. In addition, we simplified and streamlined the validation process to allow the process to be both more responsive and clear to market demands, while also allowing room for future growth of test cases. In fact, Autodesk will soon be validated to Level 2 compliance (see below) and is working with gbXML.org on Level 3 compliance.
In support of the third objective, we developed requirements for a generic validator. User stories were developed and preliminary mockups were made. The most important user story developed was to allow a user to upload their gbXML file to the gbXML.org website and view a 3D representation in their web browser. This would allow the user to identify any problems with their model visually. The second use case was for software to detect certain classes of problems with the user’s model and identify those visually in the 3D display. Finally, the use case of upgrading user models to the current gbXML schema version was identified.
Here are the tasks that were performed to achieve the above objectives:
Developed OpenStudio Models for Validation Procedure
We developed OpenStudio models for a number of the buildings in the validation procedure test suite. The test cases were derived from the ASHRAE RP-1468 documentation. The models were programmatically generated using the OpenStudio Ruby API. All scripts and model content developed for this purpose were developed under the Lesser General Public License (LGPL) open source license and are maintained in a public repository on github.com (https://github.com/GreenBuildingXML/openstudio-gbxml-validation ).
Validated OpenStudio gbXML Export/Import
We applied validation procedures to each of the OpenStudio models developed in task 1. We verified that each of the validation test cases imported correctly into the OpenStudio SketchUp plug-in. We also addressed any issues with the validation software that were found in this work. For example, the OpenStudio validation forced gbXML.org to address geometry created by thin-walled geometries, and metric-only software. Previous versions of the validator only addressed thick-walled geometry engines, and supported IP-units. The validation process and OpenStudio were made more robust as a result of this process.
Highlights of improvements/fixes to OpenStudio as a result of this project:
• correctly specifies SlabOnGrade elements
• correctly handles area calculations of sloping floors and ceilings (before calculated area as zero)
• handles most second-level space boundary translations, automatically, for simple geometries
• gbXML export up-to-date with version 6.01 of gbXML
Highlights of improvements/fixes to gbXML validation as a result of this process:
• unit of measure handling
• special procedure development for thin-walled geometry creators, opening up validation to a wider audience
• improved validation website user interface and user experience
• better error-handling and user messaging when validation fails
• improved geometry validation engine
Improved Validation Website and Documentation
The previous validation website was not hosted on the gbxml.org domain which reduced its visibility and credibility. For this task, we moved the gbxml.org website to a hosting platform that supports the validator software. The gbxml.org website was redesigned to more prominently display the validation procedure and documentation. The website now shows which software tools have been validated or are in the process of being validated. See http://www.gbxml.org for more details.
Promoted gbXML Validation Efforts
This task was performed in parallel with other tasks listed above; the purpose was to keep other software vendors and the public up to date on gbXML validation efforts. We attended the four day SimBuild 2016 Conference in Salt Lake City in August 2016 to promote gbXML validation efforts. In addition, we conducted two live webinars to explain our work.
Delivering a fully functional generic validator was out of scope for this work. Therefore, work on this area was focused on developing user stories and requirements for future work. The most important user story developed was to allow a user to upload their gbXML file to the gbXML.org website and view a 3D representation in their web browser. This would allow the user to identify any problems with their model visually. The second use case was for software to detect certain classes of problems with the user’s model and identify those visually in the 3D display. Finally, the use case of upgrading user models to the current gbXML schema version was identified.
Integration with the Autodesk Forge API was investigated as a potential solution for viewing user submitted 3D models. However, this is still a work-in-progress since the Forge API is in beta phase.
Significant Findings and Issues
During this project, we decided that 3 levels of gbXML certification, or compliance, were required to provide more clarity to the community of users and vendors.:
Level 1 compliance involves validating that a gbXML file is a well formed XML (per the W3C ISO Standard) and also conforms to the gbXML XSD (from gbXML versions 0.37 to 6.01, depending upon which version the software tool currently exports).
Level 2 compliance involves validating a gbXML file against 8 to 10 geometric “test-cases” that are based upon ASHRAE Research Project 1468, “Development of a Reference Building Information Model (BIM) for Thermal Model Compliance Testing”. Level 2 requires that second level space boundaries be correct for the simplest test cases, and pass a small subset of translation edge cases.
Level 3 compliance has yet to be fully defined. However, Level 3 does involve certain levels of vendor tool automation that goes far above and beyond Levels 1 and 2 compliance. We are currently working with Autodesk to better define Level 3 compliance (See the Future Work section for more details).
List of Issues
OpenStudio passed the following test cases:
Test Case 3: Test for proper second level space boundary representation
Test Case 6: Test for proper second level space boundary representation
Test Case 7: Test for basic pitched roof representation
Test Case 8: Test for basic sloped slab on grade representation
Test Case 12: Test for proper second level space boundary representation
Basic Whole Building Test Case 1: Test for proper second level space boundary representation
To pass these test cases, it did require that NREL make some updates to the OpenStudio SDK responsible for gbXML export since there were a few errors that were pervasive for every test case. Therefore, NREL needed to make some changes to the gbXML export feature of OpenStudio to be compliant with the validation process. gbXML provided NREL with guidance as to how each XML file should look in order to pass, which NREL took and made changes to their code base. In some cases, gbXML decided to relax configurable constraints, to allow the document to pass.
Below is the full list of issues and changes to the OpenStudio code base made as a result of this work effort:
There were no BuildingStorey definitions in any export from OpenStudio. This is a required element, but we relaxed this for validation purposes.
The Building->Area calculation that was done during export did not meet gbXML specifications for the Building Area calculation. To be fair, gbXML may not have the tightest definition in terms of the criteria for when a Space Area is included in the Building Area, but the point is, plenums and other non-occupiable spaces shouldn’t be included in the building area calculation.
Any time there was a floor that was on-grade (industry standard is when z=0, and it seems OpenStudio follows this convention) we would expect the surfaceTypeEnum for that surface to be SlabOnGrade, but OpenStudio defines these surfaces as UndergroundFloor. This needed to be changed.
Thin-Shelled geometry challenges: The fact that OpenStudio makes gbXML derived from a thin-walled geometry paradigm consistent with the building energy modeling paradigm as opposed to a BIM model posed a basic philosophical challenge for the validation process. Originally, the validator was designed for BIM-centric tools that have wall thicknesses inherent in the modeling environment. Autodesk Revit, for example, assumes that the wall thicknesses affect the volume and area calculations, even though the wall vertices go to the centerline of the thickness (as if the walls had no thickness at all). When we tried to use these same standard test files as a comparison point for a gbXML created via OpenStudio, we encountered an issue. Whereas we modeled the walls in OpenStudio as if they were on the centerline, with the same coordinates as the standard files, now the volume and area calculations came out differently than the standard files. Of course, if we tried changing things around and modeled the surfaces in OpenStudio at the inner wetted perimeter, we get the volume and area correct, but now the polygon coordinates are in a different location and don’t match the standard file PolyLoop coordinates. So either way, it is not a perfect process.
Changes to the validator code base: We made several improvements to the validation engine itself, and also to the standard test case XML files as a result of this work that has already been incorporated into the latest version of the validator. We found two problems with the standard test case files: Occasionally, there were still errors in the files that should no longer persist by the end of this process. The whole building test cases, made at the end of phase two, were particularly problematic because we made them with Honeybee out of Grasshopper. Secondly, sometimes the decimal precision was pretty extreme because for all the other test cases we used Revit in US-IP units to create the test cases originally. This meant for sloping surfaces, there was sometimes units like 9’10-11/16” that made for some difficulties when re-creating the test cases. We tightened these up so for a majority of the test cases there was much less guess-work and complexities around the units of measure.
Future Work – New gbXML Features
Further Develop Level 3 Compliance
We will be working with Autodesk to achieve Level 3 certification, which has yet to be fully defined. It does involve certain levels of vendor tool automation that goes far above and beyond Levels 1 and 2 compliance. Autodesk desires to achieve Level 3 compliance for both Autodesk Revit and Insight 360. Some examples of Autodesk-specific Level 3 automation include:
Handling ‘real’ architectural models i.e. supporting a very wide variety of modeling practices, coping with natural inaccuracies (small gaps / overlaps) and scaling from concept to detailed design
Automatic perimeter / core thermal zoning
Automatic identification of elements acting as shading (as opposed to room bounding) without manual definition
Handling ‘Sandwich’ conditions i.e. when two or more elements are adjacent or very closely adjacent and often not perfectly parallel but essentially a single gbXML surface
Definition of material thermal properties (which get very interesting when combined with sandwich conditions)
Working with or with explicit room/space objects and their associate metadata
Develop a gbXML Conversion Tool
Both NREL and Autodesk have requested that we develop a simple software tool (web-based) that converts previous versions of gbXML (i.e. – 0.37) to later or the current versions since major tools such as Autodesk Revit continue to support the 0.37 version while validation only supports the latest version. This is not an easy task on the part of the software vendor to update to the latest version since tools like Autodesk Revit have long-term “wish-list to release cycles” (often 1 or more years). Therefore, developing a conversion tool will allow these previous versions of gbXML to update to later versions.
Develop a Generic Validator and Open-Source Geometry Engine
While we have successfully developed a test-case validation tool (http://gbxml.org/validator/Pages/TestPage.aspx ), we still need to develop a “generic” validation software tool that can be used by more stakeholders including energy modelers, engineers, architects, and others. This tool should be able to validate any generic gbXML, not just test-case gbXML files. We believe we are closer than ever to achieving this vision, however, there is limited time and budget to test such concepts. Developing unit tests, and making incremental improvements to this code base, is a full-time effort that is constantly in need of development efforts.
The software development effort taken thus far to develop vendor certification tools will be leveraged for the generic validator, one that can accept any user model. A web page shall be developed on gbXML.org so a user can upload their gbXML model and the validator shall determine if there are any defects. If there are defects, the website shall provide information to alert the user to any defects that were found. A web based 3D visualization tool may be provided to visualize the uploaded model and to identify the defects in a meaningful way. We plan on using Autodesk’s Forge Viewer API to translate the gbXML geometry into a web-based model.
Create a gbXML Portal and Accompanying Web Service
Along with the generic validator wish-list item above, another long-time goal has been to create a gbXML “portal” that allows users to register and upload gbXML files for remote storage. We would create a web service (or web API) that could be accessed by authorized software tools to import and/or export gbXML files to and from this portal. This would provide the following benefits:
Different “dot” versions of gbXML could automatically be converted to the appropriate “dot” gbXML version that is supported by a consuming software tool.
Different versions of the same gbXML file that is produced by a BIM authoring tool could be stored in the portal so that a consuming tool could easily re-import it and update any changed information. Think of it as a sort of “version control” function.
If enough gbXML files are uploaded to the portal, we could begin to analyze the data and look for trends that may benefit the industry. For example, information from the uploaded models could be analyzed so as to gain insight on the use of gbXML in practice, e.g. which software tool authored the model and which defects were found.