Carmelsoft Schema Server

Carmelsoft Schema Server

SchemaServer Home 1 - Carmelsoft Blog

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:

  1. 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).
  2. 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):

  1. 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.
  2. Objective 2: Selected the seven (7) or so most important test cases.
  3. Objective 3: Developed the Schema Server web portal that included the functionality described above.
  4. 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.

SchemaServer Home - Carmelsoft Blog

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.

ProjectList - Carmelsoft Blog

You can enter the following information about a building including basic demographic information:

ProjectInfo - Carmelsoft Blog

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:

2 - Carmelsoft Blog

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:

Validate Base Schema

The View button takes the user to a new webpage that allows the user to view the XML file in different ways:

Blockchain and HVAC

Blockchain and HVAC

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.

Blockchain HVAC

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:

2 - Carmelsoft Blog
3 - Carmelsoft Blog

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.”

4 - Carmelsoft Blog

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 secure means 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:

  1. Farmer: The Farmer can harvest coffee beans, process coffee beans, pack coffee palettes, add coffee palettes, ship coffee palettes, and track authenticity.
  2. Distributor: The Distributor can buy coffee palettes and track authenticity.
  3. Retailer: The Retailer can receive coffee palettes and track authenticity.
  4. Consumer: The Consumer can buy coffee palettes and track authenticity.

Below is a UML sequence diagram that shows the actions between the various stakeholders:

5 - Carmelsoft Blog

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.

6 - Carmelsoft Blog

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.

3 - Carmelsoft Blog

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.

IPFS - Carmelsoft Blog
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).

refrigerantes - Carmelsoft Blog

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.

dapps 1024x512 1 - Carmelsoft Blog

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/ )

7 - Carmelsoft Blog

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.

8 - Carmelsoft Blog

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/ )

9 - Carmelsoft Blog

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/ )

10 - Carmelsoft Blog

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.

(https://etherscan.io)

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.

11 - Carmelsoft Blog

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.

12 - Carmelsoft Blog

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).

13 - Carmelsoft Blog

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:

14 - Carmelsoft Blog
Carmel’s DOE SBIR Grant – A 2021 Status Update

Carmel’s DOE SBIR Grant – A 2021 Status Update

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:

New horizons for infrastructure investing 1536x1536 Original Original - Carmelsoft Blog

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.

gbXMLViewer 3 - Carmelsoft Blog

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.

2 - Carmelsoft Blog

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.

1 - Carmelsoft Blog

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.

1 - Carmelsoft Blog

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.

Artificial Intelligence and Python

Artificial Intelligence and Python

Overview

During the downtime due to the pandemic-inspired shelter-in-place in California, I’ve decided to learn some new technologies and concepts related to software design. This has been my first foray into online learning using one of the e-learning platforms. In this case, I signed up for Udacity (https://www.udacity.com).

So far, I’ve been quite impressed. Of course, it does not perfectly substitute live classroom instruction, but it is still quite effective, plus I can skip to the good parts. The course I signed up for is titled “Artificial Intelligence and Python”.

While I’ve programmed scripts with Python before, I never knew that it had some many math and statistic-intensive libraries. Hence, it’s a great language for developing AI-related software since AI is all about statistics: predicting future events based upon historical information.

While the basics of Python programming is not that interesting, the libraries and tools associated with Python are fascinating and actually lots of fun to work with. This blog post will talk a bit about those libraries and also how they apply to AI. As of mid-April 2020, I have not finished the course yet, so emphasis is on the Python libraries used for AI, but not quite AI, itself.

NumPy

NumPy is a library for Python. It is short for “Numerical Python”, and it includes a large amount of functionality related to multi-dimensional arrays and matrices in addition to many mathematical functions. Users can create arrays from Python dictionaries, and then manipulate the arrays in many different ways including reshaping arrays, adding arrays, multiplying arrays, and much much more.

Here’s an example of how a simple numpy array works in Python:

1. import numpy as np
2. x = np.array([0,1,2,3,4,5,6,7,8,9])
3. print(x)
4. [0 1 2 3 4 5 6 7 8 9 10]

Line 1 imports the numpy library and renames it.
Line 2 defines a single row array with values from 0 to 9.
Line 3 prints the array and Line 4 displays it.

Let’s take it a step further:

5. x.reshape(2,5)
6. print(x)
7. [[0,1,2,3,4]
[5,6,7,8,9]]

Line 5 executes the “reshape” function that changes the shape of the array from a single row to a 2×5 array as seen in Line 7.
Other functions allow you to insert rows in an array:

8. x = np.insert(x, 1, [10,11,12,13,14], axis=0)

The above “insert” statement inserts a new row at row 1 (row numbers start at 0). The numbers it inserts are: 10,11,12,13,14. The “axis” tells whether to insert a row (0) or column (1).

You can also perform mathematics on 2 arrays including addition, subtraction, multiplication, and division. For example:

x = [[0,1,2,3,4]
[5,6,7,8,9]]

y = [[6,3,2,8,7]
[1,6,7,3,10]]

print(x + y) = [[6,4,4,11,11]
[6,12,14,11,19]]

The above “x” adds each of the elements from each row and column and creates the corresponding matrix with the added values. You can also do the same with the other mathematical functions.

There are many functions associated with numpy that can be found in lots of online documentation.

Pandas

Pandas is another Python library that deals with data analysis and manipulation. It takes the numpy arrays one step further and allow the creation of complex arrays. Let’s look at an example:

  1. import pandas as pd
  2. groceries = pd.Series(data=[30,6,’Yes’,’No’], index=[‘eggs’,’apples’,’milk’,’bread’])

Line 1 imports the Pandas library. Line 2 creates a complex matrix where the first column is the index of labels and the 2nd column is the actual data. It looks like this:

eggs 30
apples 6
milk Yes
bread No

dtype: object

If you “print groceries[‘eggs’]”. The result is: 30.

Pandas allows you to perform mathematics on values in a matrix:

print(groceries / 2) =

eggs 15
apples 3
milk Yes
bread No

You can also create a more complex matrix by creating a dictionary of Pandas series:

3. items = {‘Bob’ : pd.Series(data = [245, 25, 55], index = [‘bike’, ‘pants’, ‘watch’]),
‘Alice’ : pd.Series(data = [40, 110, 500, 45], index = [‘book’, ‘glasses’, ‘bike’, ‘pants’])}
4. shopping_carts = pd.DataFrame(items)
5. shopping_carts             

  Bob Alice
bike 245.0 500.0
book NaN 40.0
glasses NaN 110.0
pants 25.0 45.0
watch 55.0 NaN

shopping_carts[‘Bob’][‘Bike’] displays “245.0”.

You can also create a Python dictionary and then create a Panda dataframe from the dictionary along with indexes. See the following:

#Create a list of Python dictionaries
items2 = [{‘bikes’: 21, ‘pants’: 36, ‘watches’: 40},  {‘watches’: 12, ‘glasses’: 51, ‘bikes’: 18, ‘pants’:9}]

#Create a Panda DataFrame
store_items = pd.DataFrame(items2, index=[‘store 1’, ‘store 2’])

#Display the DataFrame
store_items

It displays as:

  bikes pants watches glasses
store 1 20 30 35 NaN
store 2 15 5 10 50.0

To add a column: 

store_items[‘shirts’] = [15,2]

Now, the DataFrame displays:

  bikes pants watches glasses shirts
store 1 20 30 35 NaN 15
store 2 15 5 10 50.0 2

Anaconda and Jupyter Notebooks

Now that I have covered a bit of NumPy and Pandas for manipulating data arrays, let’s delve a bit into a Python platform called Anaconda. Anaconda is a “navigator” that allows users to download any and all libraries available for the Python platform. These libraries include mathematical libraries, different types of Python compilers, artificial intelligence libraries (like PyTorch) and the Jupyter Notebook which is a web-based user interface for displaying comments and typing in Python code that runs on command. It’s a tool not necessarily to write production-level Python code, but more a tool to train and test out python code while displaying well-formatted comments.

Below is an example of a Jupyter webpage (or notebook) that includes a comments section with images and then a subsequent code section. This Jupyter notebook talks about Python tensors and Pytorch, the essentials for artificial intelligence.

Sample Jupyter page

 

Neural Networks

Neural networks have been around for a while. The basically emulate the way our brains work. The networks are built from individual parts approximating neurons which are interconnected and are the basis for how the brain learns.

“Digital” neurons are no different. They are interconnected in such a way that over time they learn and are able to apply the learned knowledge to enable useful applications such as natural language (like Alexa) and image identification (like Google Lens). It really is amazing how well it works, and the progress over the past five years alone has been remarkable. I’ll talk more about that later.

So how does it work exactly? Let’s take the example of identifying text in an image; specifically, digits 0 to 9. Just 5 years ago, this was a very complicated problem. Today, it’s a trivial one. The image below displays greyscale handwritten digits where each image is 28×28 pixels.  

Greyscale handwritten digits

Greyscale handwritten digits

The first step is to train the software or the “network” in AI lingo. This means feeding it 100s if not 1000s of sample 28×28 pixel images of digits and tagging those images with the actual numbers so the software learns what number the image represents exactly. Luckily, Pytorch includes lots of tagged training data called MNIST. This data can be used to train the network so when you present your own image of a digit, it will correctly interpret what it is.

Single digit

Single digit

The above image is an example of a greyscale “8” that is 28 x 28 pixels. This is the type of image that would be fed into the network to train it that this type of image is an “8”.

Neural Networks

Neural Networks

The above images shows a simple neural network. The far left-hand side displays the inputs (x1 and x2). In our example, the inputs would be the color of each of the 28 x 28 pixels. The values (w1 and w2) are called “weights” These weights are multiplied by each of the corresponding inputs (i.e. – dot product of two vectors) and then inputted into a function that creates an output value (0 to 9) that is compared to the actual value assigned to the image. For example, in the digit training image above (the number “8”), the tag assigned to this image is 8. Therefore, the calculated output is compared to the tagged value. If it matches, then we’ve trained it well for that particular test image and the weights will be reused. If not, then we need to go back and adjust the weights to create a new output value. This back and forth can occur 1000s of times until the correct formula is found.

A Progress Report on gbXML Validation Efforts

A Progress Report on gbXML Validation Efforts

Overview

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

Overall Goal and Objectives

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

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

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

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

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

Tasks

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

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

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

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

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

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

Significant Findings and Issues

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

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

List of Issues

OpenStudio passed the following test cases:

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

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

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

Future Work – New gbXML Features

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

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

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

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


Develop a Generic Validator and Open-Source Geometry Engine

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


Create a gbXML Portal and Accompanying Web Service

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

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

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

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

image

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

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

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

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

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

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

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

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

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

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