├── .github ├── BuildingSync_Contribution_Proposal_v1.0_2017-04-10.doc ├── CONTRIBUTING.md ├── ISSUE_TEMPLATE │ ├── bug_report.md │ └── feature_request.md ├── PULL_REQUEST_TEMPLATE.md └── workflows │ ├── CI_Labels.yml │ ├── ci.yml │ └── publish.yml ├── .gitignore ├── .rspec ├── BuildingSync.xsd ├── CHANGELOG.md ├── Gemfile ├── LICENSE.md ├── README.md ├── Rakefile ├── docs ├── developer_resources.md ├── gbXML_reference.md ├── geometry_reference.pdf ├── linking_elements.md ├── notebooks │ ├── README.md │ ├── bsync_examples │ │ ├── Primary-School-Levels1-2.md │ │ ├── Reference-PrimarySchool-L100-Audit.xml │ │ ├── Reference-PrimarySchool-L200-Audit.xml │ │ ├── Small-Office-Level-1.md │ │ ├── Small-Office-Level-2.md │ │ ├── __init__.py │ │ ├── example-smalloffice-level1.xml │ │ ├── example-smalloffice-level2.xml │ │ └── img │ │ │ ├── ESPM-Target-School.png │ │ │ ├── ESPM-Target.png │ │ │ ├── ESPM.png │ │ │ ├── L100ValidPrimarySchool.png │ │ │ ├── L200ValidPrimarySchool.png │ │ │ ├── UC-Selection.png │ │ │ ├── b1-bldg.png │ │ │ ├── b1-sc-docs.png │ │ │ ├── valid.png │ │ │ └── valid_level2.png │ ├── example-with-emissions.xml │ ├── poetry.lock │ └── pyproject.toml ├── release_instructions.md └── versioning.md ├── examples ├── ASHRAE 211 Export.xml ├── AT_example_AS_conversion_audit_report.xml ├── AT_example_NYC_audit_report_property.xml ├── AT_example_SF_audit_report.xml ├── BuildingEQ-1.0.0.xml ├── BuildingSync Website Invalid Schema.xml ├── BuildingSync Website Valid Schema.xml ├── CMS Woodlawn Campus.xml ├── DC GSA Headquarters.xml ├── Golden Test File.xml ├── LL87.xml ├── Multi-Facility Shared Systems.xml ├── Multi_building_gbxml_externalreference_geometry.xml ├── MultitenantBySubsections.xml ├── NIST Gaithersburg Campus.xml ├── Norfolk Federal Building.xml ├── Reference Building - Primary School.xml ├── Richmond Federal Building.xml └── Single_building_gbxml_externalreference_geometry.xml ├── migration_scripts ├── README.md └── upgrade_from_2.4_to_2.5.py ├── proposals ├── 2018 │ ├── Add UBID.md │ ├── Explicit_Zone_Equipment_Representation.md │ └── Harmonize PremisesAffected and LinkedPremises.md ├── 2019 │ ├── Add AuditorQualificationType enumerations.md │ ├── Add BenchmarkValue element.md │ ├── Add CondensingOperation and DraftBoundary wherever DraftType.md │ ├── Add CondensingOperation enums.md │ ├── Add DraftBoundary enums.md │ ├── Add Efficiency Units Enums.md │ ├── Add ElectricResistance to HeatingSourceType.md │ ├── Add ExteriorFloorSystemType.md │ ├── Add FuelTypes enums for Fuel oil no 5 and 6.md │ ├── Add FuelTypes enums for Fuel oil no 5 light and heavy.md │ ├── Add FuelTypes enums.md │ ├── Add Gas Engine to Chiller Compressor Driver.md │ ├── Add ID to AirInfiltrationSystem.md │ ├── Add IDs to Report and Qualification.md │ ├── Add LinkedPremises to Benchmark.md │ ├── Add MeasureName to TechnologyCategory for BuildingEnvelopeModifications.md │ ├── Add None to ControlTechnology.md │ ├── Add OccupancyClassification enums.md │ ├── Add PercentLeasedByOwner to Building.md │ ├── Add Plant Fields.md │ ├── Add PlugLoadType enums.md │ ├── Add PrimaryFuel to HeatingPlantType and CoolingPlantType.md │ ├── Add RoofCondition to RoofID Link.md │ ├── Add Scenario Notes.md │ ├── Add UDF to PackageOfMeasures.md │ ├── Add YearBurnerInstalled.md │ ├── Add to Measure Scale of Application.md │ ├── Address on Buildings.md │ ├── Audit Date Enumerations.md │ ├── BRICR Support.md │ ├── Ballast Type Enums.md │ ├── Blue Roof.md │ ├── Change Audit to Project.md │ ├── Consolidate MELs and Plug Loads.md │ ├── Consolidate Misc Gas Loads.md │ ├── Contact Roles.md │ ├── Containerization implementation.md │ ├── Controls.md │ ├── Enable Multiple Reports.md │ ├── Enable Multiple Special Roof Classifications.md │ ├── Ensure adequate containerization of lists.md │ ├── Harmonize Tightness and TightnessFitCondition elements.md │ ├── IDREF Proposal Justification.md │ ├── IDREF Proposal.md │ ├── Linear Fluorescent Enumeration.md │ ├── Make FanBased Optional.md │ ├── Modify DaylightingIlluminanceSetpoint units.md │ ├── Multiple Roofs Foundations Ceilings.md │ ├── OccupancyClassification.md │ ├── OtherEnergyGenerationTechnology.md │ ├── Ownership Enumeration.md │ ├── Package of Measures ID.md │ ├── Plant and Source Location.md │ ├── Pluralize ControlSystemType element in Plants.md │ ├── Pluralize LinkedDeliveryID.md │ ├── Pluralize PrimaryHVACControlSystemType.md │ ├── Qualifications List V2.md │ ├── Qualifications List.md │ ├── Rename GasElec to GasElectric.md │ ├── Rename OnSite to Onsite.md │ ├── Rename Root Element.md │ ├── Rename Subsection to Section.md │ ├── Replicate Site Elements in Building Element.md │ ├── Spatial Unit Occupied Percentage.md │ ├── Terminal Unit Enumerations.md │ ├── Ventilation.md │ └── gbXML_xrefs.md ├── 2020 │ ├── Add Annual Fuel Cost.md │ ├── Add Associated Cost to TimeSeries.md │ ├── Add Canadian Provinces to States.md │ ├── Add Conveyance System Condition.md │ ├── Add DHW Condition and Notes.md │ ├── Add Delivery Condition.md │ ├── Add Energy Cost Index.md │ ├── Add Energy Use Elements.md │ ├── Add Engineering Calculation.md │ ├── Add Infiltration Notes.md │ ├── Add Interval Duration.md │ ├── Add Lighting Automation System.md │ ├── Add Load Factor to Reading Type.md │ ├── Add Nonquantifiable Factors.md │ ├── Add Number of Sides to Section.md │ ├── Add Occupancy Schedule Linking.md │ ├── Add Peak Type.md │ ├── Add Resource Use Notes.md │ ├── Add Simple Impact Analysis.md │ ├── Add Space Functions Excluded from Total Area.md │ ├── Add install electrical storage measure.md │ ├── Allow Multiple Door IDs for Side.md │ ├── Allow Multiple Walls for Side.md │ ├── Allow Multiple Windows for Side.md │ ├── BuildingSync Versioning.md │ ├── Change Primary to Principal HVAC.md │ ├── Deprecate ReadingType Cost.md │ ├── NMEC Implementation.md │ ├── NMEC-Implementation │ │ └── SLR-Example.xml │ ├── Reporting Weather Data.md │ ├── Resource Use Submetering.md │ ├── Update Annual Fuel Use Native Units.md │ └── img │ │ ├── DerivedModelIO.png │ │ └── DerivedModelType.png ├── 2021 │ ├── Add AuditFilingStatus.md │ ├── Add AuditorYearsOfExperience.md │ ├── Add AverageAnnualOperatingHours.md │ ├── Add EarlyCompliance.md │ ├── Add MaximumOutsideAirFlowRate.md │ ├── Add MultiTenant.md │ ├── Add PRMS.md │ ├── Add SpatialUnits to Section.md │ ├── Add TotalCommonConditionedAboveGradeWallArea.md │ ├── Add eGRIDSubregionCodes.md │ └── Fix Implement hot aisle cold aisle design.md ├── 2022 │ ├── Add DiscountRate.md │ ├── Add Emissions for MeasureSavingsAnalysis and AnnualSavingsByFuel Elements.md │ ├── Add Emissions.md │ ├── Add Equipment ID.md │ ├── Add Package-Measure Energy Savings Analyses.md │ ├── Add RCx Auditor Qualification Types.md │ └── BuildingSync Project Haystack Example.md ├── 2023 │ ├── Add AuditCycles.md │ ├── Add Auditor Certification Types.md │ ├── Add CondenserType.md │ ├── Add FacilityEvaluationAuditDefinition.md │ ├── Add Measures for Data Center Energy Conservation Improvements.md │ ├── Add PrincipalLightingSystemType.md │ ├── Add WCM Categories.md │ ├── Add WCMs to existing Measure Categories.md │ ├── Update AuditorQualificationType.md │ └── Update PrincipalHVACSystemType.md ├── 2024 │ ├── Add AuditCycleStartDate and AuditCycleEndDate.md │ ├── Add LifeCycleSavings elements.md │ └── Add new fenestration system measures.md ├── 2025 │ └── Add Optional Elements to All Assets.md └── README.md ├── spec ├── spec_helper.rb └── validation_spec.rb ├── src ├── change_log.rb └── data_dictionary.rb └── tests ├── __init__.py └── test_bsync_examples.py /.github/BuildingSync_Contribution_Proposal_v1.0_2017-04-10.doc: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/.github/BuildingSync_Contribution_Proposal_v1.0_2017-04-10.doc -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/bug_report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report 3 | about: Create a report to help improve BuildingSync 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | 11 | 12 | **Describe the bug or data model issue** 13 | 14 | 15 | **Expected Behavior** 16 | 17 | 18 | **Actual Behavior** 19 | 20 | 21 | **Additional Context** 22 | 23 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/feature_request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Feature request 3 | about: Suggest an idea or improvement for BuildingSync 4 | title: '' 5 | labels: Feature 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Is your feature request related to a problem? Please describe.** 11 | 12 | 13 | **Describe the solution you'd like** 14 | 15 | 16 | **Describe alternatives you've considered** 17 | 18 | 19 | **Additional context** 20 | 21 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 5 | 6 | #### Any background context you want to provide? 7 | 8 | #### What does this PR do? 9 | 10 | #### How should this be manually tested? 11 | 12 | #### What are the relevant tickets? 13 | 14 | #### Screenshots (if appropriate) 15 | -------------------------------------------------------------------------------- /.github/workflows/CI_Labels.yml: -------------------------------------------------------------------------------- 1 | # This is a basic workflow to help you get started with Actions 2 | 3 | name: CI Labels 4 | 5 | # Controls when the workflow will run 6 | on: 7 | pull_request: 8 | types: 9 | # default types (i.e. default for on: pull_request) 10 | - opened 11 | - synchronize 12 | - reopened 13 | # trigger on change of labels 14 | - labeled 15 | - unlabeled 16 | branches: 17 | - develop-v3 18 | - develop-v2 19 | 20 | jobs: 21 | build: 22 | runs-on: ubuntu-latest 23 | steps: 24 | - name: Check PR Labels 25 | uses: actions/github-script@v5 26 | with: 27 | script: | 28 | const VALID_LABELS_MESSAGE = 'Success! PR has valid labels.' 29 | const BREAKING_LABELS = ['Breaking Change', 'Non-breaking Change'] 30 | 31 | const labelNames = context.payload.pull_request.labels.map(label => label.name) 32 | console.log(`INFO: Found PR labels: ${labelNames}`) 33 | 34 | const assertExactlyOneOf = (choices) => { 35 | const foundLabels = [] 36 | for (let choice of choices) { 37 | if (labelNames.includes(choice)) { 38 | foundLabels.push(choice) 39 | } 40 | } 41 | 42 | if (foundLabels.length === 1) { 43 | return true 44 | } 45 | else if (foundLabels.length === 0) { 46 | throw `PR is missing one of the labels: ${choices}` 47 | } 48 | else { 49 | throw `Expected PR to include exactly one label from ${choices}; Found ${foundLabels}` 50 | } 51 | } 52 | 53 | if (labelNames.length === 1 && labelNames[0] === 'ignore') { 54 | console.log(VALID_LABELS_MESSAGE) 55 | return 56 | } 57 | 58 | if (labelNames.length === 1 && labelNames[0] === 'No Schema Changes') { 59 | console.log(VALID_LABELS_MESSAGE) 60 | return 61 | } 62 | 63 | assertExactlyOneOf(BREAKING_LABELS) 64 | if (!labelNames.some(label => label.startsWith('Schema:'))) { 65 | throw `PR is missing a scoping label, i.e., a label starting with "Schema: ..." or "Schema: No Changes"` 66 | } 67 | console.log(VALID_LABELS_MESSAGE) 68 | -------------------------------------------------------------------------------- /.github/workflows/ci.yml: -------------------------------------------------------------------------------- 1 | name: CI 2 | 3 | on: 4 | pull_request: 5 | push: 6 | 7 | jobs: 8 | test: 9 | runs-on: ubuntu-latest 10 | steps: 11 | - uses: actions/checkout@v2 12 | - uses: ruby/setup-ruby@v1 13 | with: 14 | ruby-version: 2.7.2 15 | bundler-cache: true 16 | # Rake checks that all examples files pass. generate_data_dictionary will check to ensure there are 17 | # no name conflicts needed to generate the data dictionary. 18 | - run: | 19 | bundle exec rake 20 | bundle exec rake generate_data_dictionary -------------------------------------------------------------------------------- /.github/workflows/publish.yml: -------------------------------------------------------------------------------- 1 | name: Publish 2 | 3 | on: 4 | push: 5 | tags: 6 | - 'v*.*.*' 7 | 8 | jobs: 9 | publish: 10 | runs-on: ubuntu-latest 11 | steps: 12 | - 13 | uses: actions/checkout@v2 14 | - 15 | uses: ruby/setup-ruby@v1 16 | with: 17 | ruby-version: 2.7.2 18 | bundler-cache: true 19 | - 20 | name: Test 21 | run: bundle exec rake 22 | - 23 | name: Checkout xs3p 24 | uses: actions/checkout@v2 25 | with: 26 | repository: macintoshpie/xs3p 27 | path: xs3p 28 | - 29 | name: Build HTML 30 | run: | 31 | sudo apt install xsltproc 32 | xsltproc --output index.html xs3p/xs3p.xsl BuildingSync.xsd 33 | stat index.html 34 | - 35 | name: Build Data Dictionary 36 | run: bundle exec rake generate_data_dictionary 37 | - 38 | name: Build Changelog 39 | run: | 40 | # grab the most recent version section from the changelog 41 | python -c 'print(open("CHANGELOG.md").read().split("## ")[1])' > ${{ github.workflow }}-CHANGELOG.md 42 | cat ${{ github.workflow }}-CHANGELOG.md 43 | - 44 | name: Release with Artifacts 45 | uses: softprops/action-gh-release@v1 46 | with: 47 | files: | 48 | BuildingSync.xsd 49 | index.html 50 | docs/DataDictionary.xlsx 51 | docs/enumerations.json 52 | docs/geometry_reference.pdf 53 | body_path: ${{ github.workflow }}-CHANGELOG.md 54 | prerelease: ${{ contains(github.ref, 'pr') }} 55 | env: 56 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 57 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .idea/ 2 | .bundle 3 | build 4 | Gemfile.lock 5 | gems 6 | .bundle 7 | .DS_Store 8 | .ruby-version 9 | .python-version 10 | BuildingSync.xpr 11 | schema_documentation.csv 12 | geojson.xsd 13 | .venv 14 | *.egg-info 15 | .ipynb_checkpoints 16 | *.bak 17 | *.ipynb -------------------------------------------------------------------------------- /.rspec: -------------------------------------------------------------------------------- 1 | --require spec_helper 2 | -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source 'http://rubygems.org' 2 | 3 | gem 'rake', '~> 13.0.1' 4 | gem 'nokogiri', '>= 1.10.4' 5 | gem 'rubyXL', '~> 3.4.16' 6 | gem 'rspec', '~> 3.10.0' 7 | gem 'github_api' 8 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | BuildingSync®, Copyright (c) 2015-2021, Alliance for Sustainable Energy, LLC, and other contributors. 2 | 3 | All rights reserved. 4 | 5 | Redistribution and use in source and binary forms, with or without modification, are permitted 6 | provided that the following conditions are met: 7 | 8 | (1) Redistributions of source code must retain the above copyright notice, this list of conditions 9 | and the following disclaimer. 10 | 11 | (2) Redistributions in binary form must reproduce the above copyright notice, this list of conditions 12 | and the following disclaimer in the documentation and/or other materials provided with the distribution. 13 | 14 | (3) Neither the name of the copyright holder nor the names of any contributors may be used to endorse 15 | or promote products derived from this software without specific prior written permission from the 16 | respective party. 17 | 18 | (4) Other than as required in clauses (1) and (2), distributions in any form of modifications or other 19 | derivative works may not use the "BuildingSync" trademark or any other confusingly similar designation 20 | without specific prior written permission from Alliance for Sustainable Energy, LLC. 21 | 22 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) AND ANY CONTRIBUTORS "AS IS" AND ANY EXPRESS OR 23 | IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 24 | FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER(S), ANY 25 | CONTRIBUTORS, THE UNITED STATES GOVERNMENT, OR THE UNITED STATES DEPARTMENT OF ENERGY, NOR ANY OF 26 | THEIR EMPLOYEES, BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 27 | DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, 28 | OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 29 | STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 30 | SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 31 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # BuildingSync® 2 | 3 | ![Build Status](https://github.com/BuildingSync/schema/actions/workflows/ci.yml/badge.svg?branch=develop) 4 | 5 | BuildingSync is a building data exchange schema to better enable integration between software tools and building data 6 | workflows. The schema's original use case was focused on commercial building energy audits; however, several additional 7 | use cases have been realized including building energy modeling and more high-level generic building data exchange. 8 | 9 | BuildingSync helps streamline the data exchange process, improving the value of the data, minimizing duplication of 10 | effort for subsequent building data collection efforts (including audits), and facilitating the achievement of greater 11 | energy efficiency. This in done in part by standarizing on (a) reporting audits in an electronic format, 12 | (b) tracking proposed, implemented, and discarded energy conservation measures, and (c) storing building 13 | characteristics (at multiple levels) for audits, benchmarking, and building energy analysis. 14 | 15 | ## The BuildingSync Ecosystem 16 | 17 | BuildingSync has several documents and tools avaliable to help users understand how to best leverage BuildingSync. The 18 | list below are only a subset of the resources available. If new resources are discovered, then feel free to create 19 | a new pull request with the additions. 20 | 21 | * Generic BuildingSync information is available on the [DOE website](https://www.energy.gov/eere/buildings/buildingsync) 22 | and the [project website](https://buildingsync.net/). 23 | * [BuildingSync Examples](examples) - These examples are kept up to date and show a wide range of implementations. Any 24 | new update to BuildingSync is required to pass validation on these example files. 25 | * [BuildingSync Use Case Validator](https://buildingsync.net/validation) allows for users to determine 26 | if their instance complies with a specific use case for BuildingSync by checking if the required elements are 27 | implemented in an uploaded instance. An API is also provided for automated integration into 28 | other tools. Also, the website contains an easy way to view the entirety of the schema and how elements relate to 29 | the [Building Exchange Data Exchange Specification](https://bedes.lbl.gov/). The Validator is open sourced 30 | [here](https://github.com/BuildingSync/BuildingSync-website) 31 | * [Use Case TestSuite](https://pypi.org/project/testsuite/) provides a Python package for easier generation of BuildingSync use cases. BuildingSync use cases depend on the generation of schematron documents, which is time-consuming and difficult to implement well. The TestSuite allows users to define a use case using a more palatable CSV template, which it then turns into a Schematron document. The source code is available [here](https://github.com/BuildingSync/TestSuite). 32 | * [BuildingSync to OpenStudio/EnergyPlus](https://rubygems.org/gems/buildingsync). The translator is open sourced 33 | [here](https://github.com/BuildingSync/BuildingSync-gem). This project will translate a Level 1 (and partial Level 2) 34 | ASHRAE Energy Audit to a fully defined OpenStudio and EnergyPlus model. This project is in early Beta testing and 35 | any feedback is welcome! 36 | 37 | ## Contribution 38 | 39 | New contributions to BuildingSync are welcome. Please follow the proposal process outlined [here](proposals). 40 | 41 | -------------------------------------------------------------------------------- /Rakefile: -------------------------------------------------------------------------------- 1 | # Author: Nicholas Long 2 | 3 | # Specific gems used elsewhere 4 | require 'nokogiri' 5 | require 'rubyXL' 6 | require 'pp' 7 | require 'json' 8 | require 'csv' 9 | 10 | # Local files 11 | require_relative 'src/data_dictionary' 12 | 13 | desc 'generate data dictionary' 14 | task :generate_data_dictionary do 15 | dd = DataDictionary.new 16 | dd.generate 17 | end 18 | 19 | desc 'Convert tabs to spaces' 20 | task :remove_tabs do 21 | Dir['examples/**/*.xml', 'BuildingSync.xsd', 'proposals/**/*.xml'].each do |file| 22 | puts " Cleaning #{file}" 23 | doc = Nokogiri.XML(File.read(file)) do |config| 24 | config.default_xml.noblanks 25 | end 26 | 27 | doc.xpath('//comment()').each do |node| 28 | if node.text =~ /XMLSpy/ 29 | node.remove 30 | end 31 | end 32 | 33 | File.open(file, 'w') { |f| f << doc.to_xml(:indent => 2) } 34 | end 35 | 36 | if File.exist? "BuildingSync.json" 37 | f = JSON.parse(File.read('BuildingSync.json')) 38 | File.open('BuildingSync.json', 'w') do |file| 39 | file << JSON.pretty_generate(f) 40 | end 41 | end 42 | end 43 | 44 | csv_filename = "./schema_documentation.csv" 45 | 46 | desc 'Generate CSV of the schema\'s documentation elements' 47 | task :generate_documentation_csv do 48 | # WARNING: this task is coupled with the `update_documentation` task 49 | CSV.open(csv_filename, "w") do |csv| 50 | csv << ["file_line", "original_documentation", "updated_documentation", "xpath"] 51 | doc = Nokogiri.XML(File.read("BuildingSync.xsd")) do |config| 52 | config.default_xml.noblanks 53 | end 54 | 55 | doc.xpath('//xs:documentation', 'xs' => 'http://www.w3.org/2001/XMLSchema').each do |node| 56 | csv << ["BuildingSync.xsd:%d" % [node.line], node.text, '', node.path] 57 | end 58 | end 59 | end 60 | 61 | desc 'Update schema\'s documentation elements from CSV' 62 | task :update_documentation do 63 | # WARNING: this task is coupled with the `generate_documentation_csv` task 64 | doc = Nokogiri.XML(File.read("BuildingSync.xsd")) do |config| 65 | config.default_xml.noblanks 66 | end 67 | 68 | csv_row_number = 1 69 | CSV.foreach(csv_filename, :headers => :first_row) do |row| 70 | csv_row_number += 1 71 | updated_documentation = row.field("updated_documentation") 72 | if updated_documentation == nil || updated_documentation.length == 0 73 | next 74 | end 75 | 76 | documentation_elem = doc.xpath(row.field("xpath")) 77 | if documentation_elem.length != 1 78 | raise "%s:%d Xpath returned an unexpected number of elements (expected one)" % [csv_filename, csv_row_number] 79 | end 80 | 81 | documentation_elem[0].content = updated_documentation 82 | end 83 | 84 | File.open("BuildingSync.xsd", 'w') { |f| f << doc.to_xml(:indent => 2) } 85 | end 86 | 87 | require 'rspec/core/rake_task' 88 | # require 'ci/reporter/rake/rspec' # Always create spec reports 89 | 90 | RSpec::Core::RakeTask.new(:spec) do |spec| 91 | spec.rspec_opts = ['--format', 'progress'] 92 | spec.pattern = FileList['spec/**/*_spec.rb'] 93 | end 94 | 95 | task :default => :spec 96 | -------------------------------------------------------------------------------- /docs/developer_resources.md: -------------------------------------------------------------------------------- 1 | # Developer Resources 2 | 3 | ## Deprecation Policy 4 | 5 | Details of the deprecation policy are included in the BuildingSync XML schema file. 6 | 7 | ## Pull Requests 8 | ### Summary 9 | BuildingSync uses Pull Requests (PRs) to track and report changes to users when creating releases. Specifically, we document changes to the schema/repo by using labels on PRs, thus we require developers to add labels to all PRs. Our CI will validate labels. 10 | 11 | ### Requirements 12 | - PRs are our "source of truth" for important changes to the repo/schema 13 | - We encourage separate PRs for each "logical"/"discrete" change to the schema (especially if the changes are impactful/non-trivial to users). For example, removing an element from the schema should be separate from adding a choice to an unrelated element. 14 | - The labels for the PR indicate the implications of the changes. Our CI system will validate your labels. See [CI Labels](../.github/workflows/CI_Labels.yml) for more info. 15 | -------------------------------------------------------------------------------- /docs/gbXML_reference.md: -------------------------------------------------------------------------------- 1 | # Green Building XML (gbXML) Schema Referencing 2 | 3 | BuildingSync can reference the gbXML schema to allow gbXML-valid geometry data to be present in a BuildingSync file. The current gbXML schema can be found [here](http://www.gbxml.org/Schema_Current_GreenBuildingXML_gbXML). The current gbXML version referenced is [6.01](http://www.gbxml.org/schema/6-01/GreenBuildingXML_Ver6.01.xsd). 4 | 5 | There are two examples in the examples folder: 6 | 7 | * `Single_building_gmxml_externalreference_geometry.xml` 8 | * `Multi_building_gmxml_externalreference_geometry.xml` 9 | 10 | The examples are basic mockups of BuildingSync files with gbXML geometry data, showcasing the formatting of an end-case XML file and which validate against the both BuildingSync and gbXML schema while containing foreign gbXML data. The gbXML elements allowed are prefixed with (namespaced) with `gbXML`. 11 | 12 | The elements are primarily geometry-specific elements that are children of gbXML's `` element and can be placed inside of a BuildingSync `` element. Note that any existing IDref-type attributes in the gbXML data may cause validation errors (depending the XML validator strictness), as they are referencing ID's of elements that are from the original gbXML instance file, which will not be present in the BuildingSync instance file. These can be removed a variety of ways; here's a simple XSLT transformation which can be applied to the document: 13 | 14 | 

15 | <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
16 |     <xsl:template match="@nameOfAttributeToRemove" />
17 |     <xsl:template match="@*|node()">
18 |         <xsl:copy>
19 |             <xsl:apply-templates select="@*|node()"/>
20 |         </xsl:copy>
21 |     </xsl:template>
22 | </xsl:stylesheet>
23 | 
24 |
25 | 26 | -------------------------------------------------------------------------------- /docs/geometry_reference.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/docs/geometry_reference.pdf -------------------------------------------------------------------------------- /docs/notebooks/README.md: -------------------------------------------------------------------------------- 1 | Here you can find Jupyter Notebooks which serve as guides for using BuildingSync. Currently there are several notebooks for prototype small office and primary school buildings with ASHRAE Level 1 and 2 energy audit. 2 | 3 | # Setup 4 | 5 | - `pip install poetry` 6 | - `poetry install` 7 | - `poetry run jupyter lab` 8 | 9 | Navigate to the notebook examples (e.g., `bsync_examples/Small-Office-Level-1.md`), right click on the file and select `Open With -> Jupytext Notebook`, then walk through the example. 10 | -------------------------------------------------------------------------------- /docs/notebooks/bsync_examples/__init__.py: -------------------------------------------------------------------------------- 1 | __version__ = '0.1.0' 2 | -------------------------------------------------------------------------------- /docs/notebooks/bsync_examples/img/ESPM-Target-School.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/docs/notebooks/bsync_examples/img/ESPM-Target-School.png -------------------------------------------------------------------------------- /docs/notebooks/bsync_examples/img/ESPM-Target.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/docs/notebooks/bsync_examples/img/ESPM-Target.png -------------------------------------------------------------------------------- /docs/notebooks/bsync_examples/img/ESPM.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/docs/notebooks/bsync_examples/img/ESPM.png -------------------------------------------------------------------------------- /docs/notebooks/bsync_examples/img/L100ValidPrimarySchool.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/docs/notebooks/bsync_examples/img/L100ValidPrimarySchool.png -------------------------------------------------------------------------------- /docs/notebooks/bsync_examples/img/L200ValidPrimarySchool.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/docs/notebooks/bsync_examples/img/L200ValidPrimarySchool.png -------------------------------------------------------------------------------- /docs/notebooks/bsync_examples/img/UC-Selection.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/docs/notebooks/bsync_examples/img/UC-Selection.png -------------------------------------------------------------------------------- /docs/notebooks/bsync_examples/img/b1-bldg.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/docs/notebooks/bsync_examples/img/b1-bldg.png -------------------------------------------------------------------------------- /docs/notebooks/bsync_examples/img/b1-sc-docs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/docs/notebooks/bsync_examples/img/b1-sc-docs.png -------------------------------------------------------------------------------- /docs/notebooks/bsync_examples/img/valid.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/docs/notebooks/bsync_examples/img/valid.png -------------------------------------------------------------------------------- /docs/notebooks/bsync_examples/img/valid_level2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/docs/notebooks/bsync_examples/img/valid_level2.png -------------------------------------------------------------------------------- /docs/notebooks/pyproject.toml: -------------------------------------------------------------------------------- 1 | [tool.poetry] 2 | name = "bsync-examples" 3 | version = "0.2.0" 4 | description = "Examples for generating BuildingSync files from Python. This currently uses BuildingSync Version 2.6." 5 | authors = ["corymosiman12 ", "nllong "] 6 | 7 | [tool.poetry.dependencies] 8 | python = "^3.7.9" 9 | jupyterlab = "^3.6.8" 10 | lxml = "^4.9.1" 11 | bsyncpy = {git = "https://github.com/BuildingSync/bsyncpy.git", branch="develop" } 12 | eeweather = "^0.3.24" 13 | jupytext = "^1.13.8" 14 | 15 | [tool.poetry.dev-dependencies] 16 | pytest = "^7.3.1" 17 | 18 | [build-system] 19 | requires = ["poetry>=0.12"] 20 | build-backend = "poetry.masonry.api" 21 | -------------------------------------------------------------------------------- /docs/release_instructions.md: -------------------------------------------------------------------------------- 1 | # Releasing 2 | 3 | Follow the steps below when releasing a new version 4 | 5 | ### Prepare for release 6 | 7 | * Checkout develop and pull the most recent changes 8 | 9 | * Update the Version in the header of the XSD in three places: 10 | * Update version the `/xs:schema@version`. 11 | * Update version in the "schema title", at `/xs:schema/xs:annotation/xs:documentation[1]`. 12 | * If creating an official release (i.e., you are NOT creating a pre-release), add the version as an enumeration to the `auc:BuildingSync` `version` attribute with the latest version. Though we historically added some pre-releases to `@version`, they should no longer be included. 13 | 14 | * Update the CHANGELOG.md to include the latest changes, and the most recent version: 15 | * Obtain [Github API token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) for the next step. 16 | * Run the change_log.rb script (e.g., ruby src/change_log.rb -t TOKEN_string -s 2019-12-21). The date range must span from the last official release (ie don't start at a pre-release) until the current date. 17 | * Copy the results of this into the CHANGELOG. Remove items that are not useful to an end user such as version bumps, formatting, etc. 18 | * Create a Pull Request (prep release) into `develop`: 19 | * Mark the PR with an `ignore` label to prevent the PR from being added to future change logs. 20 | * Merge the PR. 21 | 22 | * Create a Pull Request (release) into `main`: 23 | * Mark the PR with an `ignore` label to prevent the PR from being added to future change logs. 24 | * Merge the PR. 25 | 26 | ### Tag and release 27 | 28 | Check out main locally, pull changes, and create a tag and push it 29 | ```bash 30 | git checkout main && git pull 31 | git tag -a v -m "" [SHA] 32 | ``` 33 | Where `v` is a valid [semantic version](https://semver.org/) (e.g., `v1.2.3` or `v1.2.3-pr.1`) and `` is the tagging message (e.g. "First official release"). [SHA] is used for specific commit (when the tag does not correspond to the latest commit). See [Versioning](versioning.md) for more information. 34 | ```bash 35 | # push the tag 36 | git push --tags origin 37 | ``` 38 | 39 | This should trigger a GitHub workflow for building and publishing the release. If publishing a pre-release, you are done. Otherwise, once the release has been successfully published on GitHub, continue. 40 | 41 | ### Update BuildingSync examples and version references 42 | Walk through all the files and documents in the develop branch to update the version references to the newest release. Update examples in [notebook](https://github.com/BuildingSync/schema/tree/develop-v2/docs/notebooks) and [examples](https://github.com/BuildingSync/schema/tree/develop-v2/examples) as required by the new version. This will be the first PR for the new release, and is a prerequisite for updating the website in the next step. 43 | 44 | ### Update BuildingSync Website 45 | 46 | At this point the GitHub action for publishing the release should be finished. Now we need to update the docs/data in [this repo](https://github.com/BuildingSync/BuildingSync-website). Read the README in that repository. 47 | 48 | 49 | 50 | -------------------------------------------------------------------------------- /docs/versioning.md: -------------------------------------------------------------------------------- 1 | # Versioning 2 | 3 | Having consistent meanings of versions is helpful to users. By the version alone, a user can determine whether or not an implementation of BuildingSync supports their existing documents or not. 4 | 5 | Since version 2.0.0 (post 2016 version reset), BuildingSync attempts to follow [semantic versioning](https://semver.org/). Since semantic versioning (semver) is more directed towards APIs, it can be helpful to translate the meaning of breaking changes, non-breaking features, and patches. When thinking about the API of an xml schema, consider XPaths, when and how they break, as well as document validation, when and how historical documents are no longer valid, as these are the use cases of XML documents. 6 | 7 | Note that BuildingSync reset the numbering of the schema in 2016. 8 | 9 | ## Breaking changes 10 | These are the changes that require a new MAJOR version. Generally this would be any time where there could exist a historical document that would not validate against the new schema. This would include: 11 | 12 | - adding a required element/attribute that was not previously required 13 | - moving the location of an existing element or changing its name (e.g. moving order in sequence or to different parent) 14 | - changing to an incompatible type (e.g. decimal to integer) 15 | - changing the restrictions for a simple type to something which is not the superset of the previous restriction 16 | 17 | ## Non-breaking features 18 | These are the changes that require a new MINOR version. This would include any changes which are meaningful changes to the schema, but do not break the validation of historical documents. For example: 19 | 20 | - adding a new non-required element/attribute 21 | - changing a simple type to a compatible type (e.g. decimal to string) 22 | - adding a new enum option for a simple type 23 | 24 | ## Patches 25 | These are the changes that require a new PATCH version. This would include changes which do not meaningfully change the schema. For example: 26 | 27 | - updating the documentation 28 | - restructuring the XSD without changing the schema (e.g. turning an inline element definition into a reference or creating a new type) 29 | -------------------------------------------------------------------------------- /migration_scripts/README.md: -------------------------------------------------------------------------------- 1 | These scripts each take in a BuildingSync file and upgrade it from one schema to another. ex: 2 | 3 | ``` 4 | python migration_scripts/upgrade_from_2.4_to_2.5.py path/to/file 5 | ``` 6 | or, if you want to write to a new file: 7 | ``` 8 | python migration_scripts/upgrade_from_2.4_to_2.5.py path/to/file --to_file ./new_file.xml 9 | ``` 10 | 11 | The migration script will only be created for two adjacent versions that might lead to validation failures when updating the older BuildingSync XML to newer version (except for required version referencing update). -------------------------------------------------------------------------------- /migration_scripts/upgrade_from_2.4_to_2.5.py: -------------------------------------------------------------------------------- 1 | """ 2 | Simply makes UsefulLife an int. 3 | """ 4 | import argparse 5 | import logging 6 | from lxml import etree as ET 7 | 8 | 9 | logging.basicConfig(level=logging.INFO) 10 | 11 | 12 | def get_args(): 13 | parser = argparse.ArgumentParser() 14 | parser.add_argument("from_file", type=str, help="path to file to update") 15 | parser.add_argument( 16 | "--to_file", 17 | type=str, 18 | help="path to write update to", 19 | required=False, 20 | default=None, 21 | ) 22 | return parser.parse_args() 23 | 24 | 25 | def update_version(tree): 26 | root = tree.getroot() 27 | 28 | root.set("version", "2.5.0") 29 | root.insert(0, ET.Comment('This BuildingSync v2.5 document was generated from a BuildingSync v2.4 document via the BuildingSync migration scripts')) 30 | 31 | 32 | def update_usefulLife(tree): 33 | for usefulLife in tree.findall( 34 | ".//*{http://buildingsync.net/schemas/bedes-auc/2019}UsefulLife" 35 | ): 36 | new_value = str(round(float(usefulLife.text))) 37 | if new_value != usefulLife.text: 38 | logging.info( 39 | f"changing {tree.getelementpath(usefulLife)} value from {usefulLife.text} to {new_value}" 40 | ) 41 | usefulLife.text = new_value 42 | 43 | 44 | def main(): 45 | from_file, to_file = get_args().from_file, get_args().to_file 46 | 47 | try: 48 | tree = ET.parse(from_file) 49 | except (FileNotFoundError, ET.ParseError) as e: 50 | exit(f"File could not be read \n{e} \naborting...") 51 | 52 | update_version(tree) 53 | update_usefulLife(tree) 54 | 55 | if to_file is None: 56 | to_file = from_file 57 | 58 | tree.write(to_file) 59 | 60 | 61 | if __name__ == "__main__": 62 | main() 63 | -------------------------------------------------------------------------------- /proposals/2018/Add UBID.md: -------------------------------------------------------------------------------- 1 | # Add UBID to the set of IdentifierLabels 2 | 3 | ## Overview 4 | 5 | 6 | The BuildingSync XML (BSync) schema has several identifiers for buildings shown below. The purpose of this proposal 7 | would be to add UBID as an enumeration. 8 | 9 | 10 | ```xml 11 | 12 | 13 | Identifier used in a specific program or dataset. There can be multiple instances of Identifier Types within a dataset, such as a Listing ID, a Tax Map Number ID, and a Custom ID. 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | ``` 33 | 34 | ## Justification 35 | 36 | The UBID is becoming the defacto standard for defining the location of a building/facility. Adding the UBID to the list will give users the ability to enter the UBID without using the `IdentifierCustomName` object. 37 | 38 | ## Implementation 39 | 40 | This proposal is: 41 | 1. To add the following enumeration to the IdentifierLabel element. 42 | 43 | ```xml 44 | 45 | ``` 46 | 47 | ## References 48 | 49 | More information on the UBID can be found [here](https://buildingid.pnnl.gov/) 50 | -------------------------------------------------------------------------------- /proposals/2018/Explicit_Zone_Equipment_Representation.md: -------------------------------------------------------------------------------- 1 | # Change Representation of Zone Equipment # 2 | 3 | ## Overview ## 4 | The schema presently does not allow for the representation of the presence of delivery-type zone equipment without specifying the type of zone equipment. Workarounds are possible, but all involve adding either additional enumerations or the use of user-defined fields. The proposed change splits the fan-based delivery equipment into two parts and branches on "zone equipment or not" before branching on the equipment type. 5 | 6 | ## Justification ## 7 | The current schema for representation of delivery at 8 | 9 | Audits/Audit/Systems/HVACSystems/HVACSystem/HeatingAndCoolingSystems/Delivery/DeliveryType 10 | 11 | branches on 12 | 13 | * Fan based 14 | * Convection 15 | * Radiant 16 | * Other 17 | 18 | Note that it is not possible to simply represent that there is zone equipment present without specifying the type. For a detailed audit, it is logical to assume that the auditor will see the equipment and will be able to input the type. However, for higher-level audits (e.g. ASHRAE level 1 or 2) it may be desirable to note that zone equipment is present without specifying the type. The ASHRAE Standard 211 spreadsheet does this on the "L2 - HVAC" sheet. In the category of "Cooling Distribution Equipment Type", two checkboxes ask about zone equipment but not what type of zone equipment: 19 | 20 | * Hydronic to zone equipment (e.g. fan coil units, packaged terminal units or radiators) 21 | * Refrigerant to zone equipment (e.g. fan coil units, packaged terminal units or radiators) 22 | 23 | All of the other checkboxes can be represented without ambiguity. Non-breaking workarounds are available (e.g. add an enumeration value), but this means that the representations of the various systems are inconsistent. A breaking change that makes the representations consistent is preferable, and a making the breaking change now instead of a breaking change later will reduce the impact of the change. 24 | 25 | ## Implementation ## 26 | There are three options for implementation of the Zone Equipment representation in the Delivery section. 27 | 28 | Originally Proposed: This is what we understood to be proposed originally. It is specified with no missing relevent parent/child relationships. Pro: Reflects request. Con: Organization of information is a bit confusing with having the ZoneEquipment as a child of the FanBasedDistributionType. 29 | 30 | Delivery 31 | - DeliveryType 32 | - FanBased 33 | - FanBasedDistributionType 34 | - CentralAirDistribution 35 | - ZoneEquipment (New) 36 | - FanCoil 37 | - Convection 38 | - Radiant 39 | - Other 40 | - Other (New) 41 | 42 | Recommended Option A: This reflects what was requested originally with small modifications to make it more intuitive where CentralAirDistribution and ZoneEquipment are children of DeliveryType not FanBasedDistributionType. Pro: Similar to request. Con: ZoneEquipment has children (Convection, Radiant, etc) which might be limiting to use cases. 43 | 44 | Delivery 45 | - DeliveryType 46 | - CentralAirDistribution 47 | - ZoneEquipment (New) 48 | - FanBased 49 | - FanBasedDistributionType 50 | - FanCoil 51 | - Convection 52 | - Radiant 53 | - Other 54 | - Other (New) 55 | 56 | Recommended Option B: This is furthest from what was originally requested but would meet the goals of the 211 use case cleanly. Pro: Structure is intuitive. Con: Most changes. 57 | 58 | Delivery 59 | - DeliveryZoningType (New) 60 | - CentralAirDistribution 61 | - ZoneEquipment (New) 62 | - Other (New) 63 | - DeliveryType 64 | - FanBased 65 | - FanBasedDistributionType 66 | - FanCoil 67 | - Convection 68 | - Radiant 69 | - Other 70 | 71 | ## References ## 72 | https://xp20.ashrae.org/211-2018/ tab L2-HVAC -------------------------------------------------------------------------------- /proposals/2018/Harmonize PremisesAffected and LinkedPremises.md: -------------------------------------------------------------------------------- 1 | # Harmonize Definitions of `PremisesAffected` and `LinkedPremises` Elements 2 | 3 | ## Overview 4 | 5 | The BuildingSync XML (BSXML) schema provides more than one way to relate a concept to other elements, including `Site`, `Facility` and `Subsection` elements: the `PremisesAffected` and `LinkedPremises` elements. 6 | 7 | The duplication of functionality is confusing for end-users and downstream software developers. 8 | 9 | ## Justification 10 | 11 | An example of the usage of the `PremisesAffected` element (within the context of a `Measure` element) is: 12 | 13 | ```xml 14 | 15 | 16 | 17 | 18 | 10 19 | 20 | 21 | 20 22 | 23 | 24 | 40 25 | 26 | 27 | 28 | 29 | ``` 30 | 31 | A corresponding example of the usage of the `LinkedPremises` element is: 32 | 33 | ```xml 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | ``` 46 | 47 | Note that: 48 | 49 | * The `PremisesAffected` element is a child of the `Measure` element. Within each `PremiseAffected` element, there may be a child `MeasureCoverage` element. 50 | * Unlike the `LinkedPremises` element and its child elements, the `PremiseAffected` element does not indicate the type of the referenced element (the target of the `IDref` attribute). 51 | 52 | ## Implementation 53 | 54 | This proposal is: 55 | 1. To remove the `PremisesAffected` element and to replace its use with that of the `LinkedPremises` element. 56 | 2. To remove the `MeasureCoverage` element and to replace its use with that of the `FloorAreas` element. 57 | 58 | For example: 59 | 60 | ```xml 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | Tenant 69 | 10 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | Tenant 79 | 20 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | Tenant 89 | 40 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | ``` 98 | 99 | Note that: 100 | * Using XSD, the `LinkedPremises` element can be defined as a child element of the `Measure` element (with optional `MeasureCoverage` elements). 101 | * The `LinkedPremises` structure indicates the type of the referenced element. 102 | * The `FloorAreaType` element indicates the floor area type ("Tenant" in the above example). 103 | 104 | ## References 105 | 106 | n/a 107 | -------------------------------------------------------------------------------- /proposals/2019/Add AuditorQualificationType enumerations.md: -------------------------------------------------------------------------------- 1 | # AuditorQualificationType - Add Enumerations 2 | 3 | ## Overview 4 | 5 | `auc:AuditorQualificationType` is missing relevant enumerations. 6 | 7 | ## Justification 8 | 9 | In Audit Template, an audit team member may have AABC, AEE and/or ASHRAE qualifications. 10 | 11 | ## Implementation 12 | 13 | This proposal is to add the following enumerations to the `auc:AuditorQualificationType` element: 14 | * "Associated Air Balance Council (AABC) Certified Member Agency" [1] 15 | * "Associated Air Balance Council (AABC) Test and Balance Technician" [1] 16 | * "Association of Energy Engineers Certified Carbon Reduction Manager (CRM)" [2] 17 | * "Association of Energy Engineers Certified Sustainable Development Professional (CSDP)" [2] 18 | * "Association of Energy Engineers Certified Power Quality Professional (CPQ)" [2] 19 | * "Association of Energy Engineers Certified Demand Side Manager (CDSM)" [2] 20 | * "Association of Energy Engineers Certified Energy Procurement Professional (CEP)" [2] 21 | * "Association of Energy Engineers Certified Lighting Efficiency Professional (CLEP)" [2] 22 | * "Association of Energy Engineers Certified Measurement & Verification Professional (CMVP)" [2] 23 | * "Association of Energy Engineers Certified GeoExchange Designer Program (CGD)" [2] 24 | * "Association of Energy Engineers Certified Business Energy Professional (BEP)" [2] 25 | * "Association of Energy Engineers Certified Industrial Energy Professional (CIEP)" [2] 26 | * "Association of Energy Engineers Certified Water Efficiency Professional (CWEP)" [2] 27 | * "Association of Energy Engineers Energy Efficiency Practitioner (EEP)" [2] 28 | * "Association of Energy Engineers Renewable Energy Professional (REP)" [2] 29 | * "Association of Energy Engineers Distributed Generation Certified Professional (DGCP)" [2] 30 | * "Association of Energy Engineers Certified Building Energy Simulation Analyst (BESA)" [2] 31 | * "Association of Energy Engineers Performance Contracting and Funding Professional (PCF)" [2] 32 | * "Association of Energy Engineers Certified Residential Energy Auditor (REA)" [2] 33 | * "Association of Energy Engineers Certified Building Commissioning Firm Program (CBCF)" [2] 34 | * "Association of Energy Engineers Certified Green Building Engineer (GBE)" [2] 35 | * "ASHRAE Building Commissioning Professional (BCxP)" [3] 36 | * "ASHRAE Building Energy Modeling Professional (BEMP)" [3] 37 | 38 | ## References 39 | 40 | 1. http://www.hvactab.com/en/certificationlicenses/aabc/ 41 | 2. https://www.aeecenter.org/certifications 42 | 3. https://www.ashrae.org/professional-development/ashrae-certification 43 | -------------------------------------------------------------------------------- /proposals/2019/Add BenchmarkValue element.md: -------------------------------------------------------------------------------- 1 | # Add BenchmarkValue element 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `auc:BenchmarkValue` child element to the `auc:Benchmark` element. 6 | 7 | ## Justification 8 | 9 | The `auc:Assessment` element (a child element of the `auc:Building` element) provides a mechanism to assert programs that issue energy labels, ratings, scores, certifications, etc., at the building level; however, there is no corresponding mechanism at the scenario level. 10 | 11 | The `auc:Benchmark` element (a child element of the `auc:ScenarioType` element) is available; however, there is nowhere within the schema to assert the calculated score or rating. 12 | 13 | ## Implementation 14 | 15 | 1. Add `auc:BenchmarkValue` child element to `auc:Benchmark` element. 16 | 17 | ## References 18 | 19 | N/A 20 | -------------------------------------------------------------------------------- /proposals/2019/Add CondensingOperation and DraftBoundary wherever DraftType.md: -------------------------------------------------------------------------------- 1 | # CondensingOperation and DraftBoundary - Add Wherever DraftType is Present 2 | 3 | ## Overview 4 | 5 | The `auc:CondensingOperation` and `auc:DraftBoundary` elements are very useful for disambiguating the vent type that is specified by a given `auc:DraftType` element. 6 | 7 | ## Justification 8 | 9 | Currently, the `auc:CondensingOperation` and `auc:DraftBoundary` elements are not available in all locations where the `auc:DraftType` is present. 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | 1. Promote `auc:CondensingOperation` to a top-level enumeration (so that it can be reused). 15 | 2. Add `auc:DraftBoundary` element to `auc:Furnace` and `auc:Boiler` elements. 16 | 3. Add `auc:CondensingOperation` and/or `auc:DraftBoundary` elements to `auc:Combustion` elements. 17 | 18 | ## References 19 | 20 | n/a 21 | -------------------------------------------------------------------------------- /proposals/2019/Add CondensingOperation enums.md: -------------------------------------------------------------------------------- 1 | # CondensingOperation - Add Enumerations 2 | 3 | ## Overview 4 | 5 | The `auc:CondensingOperation` element should be an enumeration. 6 | 7 | ## Justification 8 | 9 | Currently, the `auc:CondensingOperation` element is Boolean-valued, asserting that a furnace or boiler is either condensing or non-condensing. 10 | As such, it is not possible to assert that a furnace or boiler is near-condensing. 11 | 12 | ## Implementation 13 | 14 | This proposal is to replace the definition of the `auc:CondensingOperation` element with an enumeration of the following values: 15 | * "Condensing" 16 | * "Near-Condensing" 17 | * "Non-Condensing" 18 | * "Other" 19 | * "Unknown" 20 | 21 | ## References 22 | 23 | n/a 24 | -------------------------------------------------------------------------------- /proposals/2019/Add DraftBoundary enums.md: -------------------------------------------------------------------------------- 1 | # DraftBoundary - Add Enumerations 2 | 3 | ## Overview 4 | 5 | The current definition `auc:DomesticHotWaterType` element and its child elements is not sufficient to distinguish between direct- and indirect-fired, instantaneous water heaters. 6 | 7 | ## Justification 8 | 9 | In both cases, the BuildingSync XML is: 10 | 11 | ``` 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | ``` 20 | 21 | ## Implementation 22 | 23 | This proposal is to add a `` element with the following enumerations: 24 | * "Direct" 25 | * "Direct indirect" 26 | * "Indirect" 27 | * "Other" 28 | 29 | With this proposal, direct- and indirect-fired, instantaneous water heaters are asserted as follows: 30 | 31 | **Direct-fired, instantaneous:** 32 | 33 | ``` 34 | 35 | 36 | 37 | 38 | Direct 39 | 40 | 41 | 42 | 43 | ``` 44 | 45 | **Indirect-fired, instantaneous:** 46 | 47 | ``` 48 | 49 | 50 | 51 | 52 | Indirect 53 | 54 | 55 | 56 | 57 | ``` 58 | 59 | ## References 60 | 61 | n/a 62 | -------------------------------------------------------------------------------- /proposals/2019/Add Efficiency Units Enums.md: -------------------------------------------------------------------------------- 1 | # AnnualCoolingEfficiencyUnits, AnnualHeatingEfficiencyUnits and WaterHeaterEfficiencyType - Add Enumerations And Harmonize Names 2 | 3 | ## Overview 4 | 5 | The `auc:AnnualCoolingEfficiencyUnits` and `auc:AnnualHeatingEfficiencyUnit` elements are inconsistently named. 6 | 7 | The `auc:AnnualHeatingEfficiencyUnits` and `auc:WaterHeaterEfficiencyType` elements are missing enumerations. 8 | 9 | ## Justification 10 | 11 | The name of the `auc:AnnualCoolingEfficiencyUnits` element is pluralized, whereas the name of the `auc:AnnualHeatingEfficiencyUnit` element is not. 12 | 13 | In Audit Template, "Thermal Efficiency" is a valid unit for heating sources. 14 | 15 | In Audit Template, "AFUE" is a valid unit for domestic hot water systems. 16 | 17 | ## Implementation 18 | 19 | This proposal is to: 20 | 21 | 1. Rename `auc:AnnualHeatingEfficiencyUnit` to `auc:AnnualHeatingEfficiencyUnits` (so that is consistent with `auc:AnnualCoolingEfficiencyUnits`). 22 | 23 | 2. Add the following enumerations to the `auc:AnnualHeatingEfficiencyUnits` element: 24 | * "Thermal Efficiency" 25 | 26 | 3. Add the following enumerations to the `auc:WaterHeaterEfficiencyType` element: 27 | * "AFUE" 28 | 29 | ## References 30 | 31 | n/a 32 | -------------------------------------------------------------------------------- /proposals/2019/Add ElectricResistance to HeatingSourceType.md: -------------------------------------------------------------------------------- 1 | # HeatingSourceType - Add ElectricResistance 2 | 3 | ## Overview 4 | 5 | Add `auc:ElectricResistance` to the choice for `auc:HeatingSourceType`. 6 | 7 | ## Justification 8 | 9 | In Audit Template, electric resistance is a valid heating source type; however, it is not a valid `auc:HeatingSourceType` in BuildingSync XML. 10 | 11 | It should be noted that electric resistance is currently valid as a `auc:DirectTankHeatingSource` and/or `auc:InstantaneousWaterHeatingSource` in BuildingSync XML. 12 | 13 | ## Implementation 14 | 15 | This proposal is to add `auc:ElectricResistance` to the choice for `auc:HeatingSourceType`. 16 | 17 | ## References 18 | 19 | n/a 20 | -------------------------------------------------------------------------------- /proposals/2019/Add ExteriorFloorSystemType.md: -------------------------------------------------------------------------------- 1 | # ExteriorFloorSystemType - Add New Element 2 | 3 | ## Overview 4 | 5 | > "**EXTERIOR FLOOR/SOFFIT** is a horizontal exterior partition, or a horizontal demising partition, under conditioned space. For low-rise residential occupancies, exterior floors also include those on grade." [1] 6 | 7 | Or simply put: A raised floor exposed to air. 8 | 9 | ## Justification 10 | 11 | Currently, BuildingSync does not support the description of exterior floors. 12 | 13 | ## Implementation 14 | 15 | This proposal is to: 16 | 17 | 1. Reify the following elements so that they can be reused: 18 | * `auc:Finish` 19 | * `auc:Color` 20 | * `auc:FramingMaterial` 21 | * `auc:ExteriorRoughness` 22 | 23 | 2. Add an `auc:ExteriorFloorSystemType` element with `@ID` and `@Status` attributes and the following child elements: 24 | * `ExteriorFloorConstruction` → `auc:EnvelopeConstructionType` 25 | * `ExteriorFloorFinish` → `auc:Finish` 26 | * `ExteriorFloorColor` → `auc:Color` 27 | * `ExteriorFloorRValue` 28 | * `ExteriorFloorUFactor` 29 | * `ExteriorFloorFramingMaterial` → `auc:FramingMaterial` 30 | * `ExteriorFloorFramingSpacing` 31 | * `ExteriorFloorFramingDepth` 32 | * `ExteriorFloorFramingFactor` 33 | * `ExteriorFloorExteriorSolarAbsorptance` 34 | * `ExteriorFloorExteriorThermalAbsorptance` 35 | * `InteriorVisibleAbsorptance` 36 | * `ExteriorRoughness` → `auc:ExteriorRoughness` 37 | * `Quantity` → `auc:Quantity` 38 | * `YearInstalled` → `auc:YearInstalled` 39 | * `UserDefinedFields` → `auc:UserDefinedFields` 40 | 41 | 3. Add an `auc:ExteriorFloorSystems` element to the `auc:Systems` element. 42 | 43 | 4. Add an `auc:ExteriorFloors` element to the `auc:Section` element. 44 | 45 | ## References 46 | 47 | 1. [2016 BUILDING ENERGY EFFICIENCY STANDARDS / Efficiency Standards, California Code of Regulations, Title 24, Part 6 / Subchapter 1 - All Occupancies—General Provisions / SECTION 100.1 – DEFINITIONS AND RULES OF CONSTRUCTION](https://energycodeace.com/site/custom/public/reference-ace-2016/index.html#!Documents/section1001definitionsandrulesofconstruction.htm) 48 | -------------------------------------------------------------------------------- /proposals/2019/Add FuelTypes enums for Fuel oil no 5 and 6.md: -------------------------------------------------------------------------------- 1 | # FuelTypes - Add Enumerations for Fuel oil no 5 and Fuel oil no 6 2 | 3 | ## Overview 4 | 5 | The `auc:FuelTypes` element is missing enumerations. 6 | 7 | ## Justification 8 | 9 | In Audit Template, "Fuel oil no 5" and "Fuel oil no 6" are valid energy types. 10 | 11 | ## Implementation 12 | 13 | This proposal is to add the following enumerations to the `auc:FuelTypes` element: 14 | * "Fuel oil no 5" 15 | * "Fuel oil no 6" 16 | 17 | ## References 18 | 19 | n/a 20 | -------------------------------------------------------------------------------- /proposals/2019/Add FuelTypes enums for Fuel oil no 5 light and heavy.md: -------------------------------------------------------------------------------- 1 | # FuelTypes - Add Enumerations for Fuel oil no 5 light and heavy 2 | 3 | ## Overview 4 | 5 | The `auc:FuelTypes` element is missing enumerations. 6 | 7 | ## Justification 8 | 9 | In Audit Template, "Fuel oil no 5 (light)" and "Fuel oil no 5 (heavy)" are valid energy types. 10 | 11 | ## Implementation 12 | 13 | This proposal is to add the following enumerations to the `auc:FuelTypes` element: 14 | * "Fuel oil no 5 (light)" 15 | * "Fuel oil no 5 (heavy)" 16 | 17 | ## References 18 | 19 | n/a 20 | -------------------------------------------------------------------------------- /proposals/2019/Add FuelTypes enums.md: -------------------------------------------------------------------------------- 1 | # FuelTypes - Add Enumerations 2 | 3 | ## Overview 4 | 5 | The `auc:FuelTypes` element is missing enumerations. 6 | 7 | ## Justification 8 | 9 | The assertion of "delivered", "exported", "metered" and "onsite generated" characteristics for fuel types is a required input for ASHRAE Standard 211 [1]. 10 | 11 | The assertion of specific fuel types, e.g., "Biofuel B5" and not "Biofuel", is a required input for ASHRAE Standard 211 [1]. 12 | 13 | ## Implementation 14 | 15 | This proposal is to add the following enumerations to the `auc:FuelTypes` element: 16 | * "Electricity-Exported" 17 | * "Electricity-Onsite generated" 18 | * "Biofuel B5" 19 | * "Biofuel B10" 20 | * "Biofuel B20" 21 | * "Dual fuel" 22 | * "Gasoline" 23 | * "Other delivered-Exported" 24 | * "Other delivered-Onsite generated" 25 | * "Other metered-Exported" 26 | * "Other metered-Onsite generated" 27 | * "Thermal-Exported" 28 | * "Thermal-Onsite generated" 29 | 30 | ## References 31 | 32 | 1. https://www.ashrae.org/technical-resources/bookstore/standards-180-and-211 33 | -------------------------------------------------------------------------------- /proposals/2019/Add Gas Engine to Chiller Compressor Driver.md: -------------------------------------------------------------------------------- 1 | # ControlTechnology - Add Gas Engine to Chiller Compressor Driver 2 | 3 | ## Overview 4 | 5 | The `BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/Plants/CoolingPlants/CoolingPlant/Chiller/ChillerCompressorDriver` enumeration does not have a gas engine. 6 | 7 | ## Justification 8 | 9 | Chillers can be driven by a gas engine. 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | 15 | Add the following enumerations to ``: 16 | * Gas Engine 17 | 18 | After complete, the full list of enums will be: 19 | 20 | ``` 21 | 22 | 23 | 24 | 25 | 26 | 27 | ``` 28 | 29 | ## References 30 | 31 | n/a 32 | -------------------------------------------------------------------------------- /proposals/2019/Add ID to AirInfiltrationSystem.md: -------------------------------------------------------------------------------- 1 | # OccupancyClassification - Add Enumerations 2 | 3 | ## Overview 4 | 5 | AirInfiltrationSystem element does not have an ID element. Most other "system" elements do. 6 | 7 | ## Justification 8 | 9 | There exists a need to have an ID attribute on the AirInfiltrationSystem element. 10 | 11 | ## Implementation 12 | 13 | This proposal is to add an ID attribute to path: 14 | BuildingSync/Facilities/Facility/Systems/AirInfiltrationSystems/AirInfiltrationSystem 15 | 16 | ## References 17 | 18 | N/A 19 | -------------------------------------------------------------------------------- /proposals/2019/Add IDs to Report and Qualification.md: -------------------------------------------------------------------------------- 1 | # Add the Address Element to a Building 2 | 3 | ## Overview 4 | 5 | There is no way to locally identify a Qualification or Report in BuildingSync. 6 | 7 | ## Justification 8 | 9 | The exists a need for certain users to have a unique ID on a Report and/or a Qualification. This will allow the user to keep external data sources linked with the Report or Qualification as needed. 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | 1. Add an attribute @ID on auc:Qualification 15 | 2. Add an attribute @ID on auc:Report 16 | 17 | ## References 18 | 19 | N/A 20 | -------------------------------------------------------------------------------- /proposals/2019/Add LinkedPremises to Benchmark.md: -------------------------------------------------------------------------------- 1 | # Add LinkedPremises child element to Benchmark element 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `auc:LinkedPremises` child element to the `auc:Benchmark` element. 6 | 7 | ## Justification 8 | 9 | As discussed in https://github.com/BuildingSync/schema/issues/152, there is a need to associate benchmarking data with specific premises and floor areas. 10 | 11 | ## Implementation 12 | 13 | 1. Add `auc:LinkedPremises` child element to `auc:Benchmark` element. 14 | 15 | ## References 16 | 17 | N/A 18 | -------------------------------------------------------------------------------- /proposals/2019/Add MeasureName to TechnologyCategory for BuildingEnvelopeModifications.md: -------------------------------------------------------------------------------- 1 | # BuildingEnvelopeModifications - Add MeasureName to TechnologyCategory 2 | 3 | ## Overview 4 | 5 | This proposal is to add a new `auc:MeasureName` to the `auc:TechnologyCategory` for "BuildingEnvelopeModifications". 6 | 7 | ## Justification 8 | 9 | Excerpt from [1]: 10 | 11 | > New York City’s building and fire codes now allow you to either partially or fully close elevator and stairwell shaft vents. 12 | 13 | ## Implementation 14 | 15 | Add the following `auc:MeasureName` enumerations to the following `auc:TechnologyCategory` elements: 16 | * BuildingEnvelopeModifications 17 | * Close elevator and/or stairwell shaft vents 18 | 19 | ## References 20 | 21 | 1. https://retrofitaccelerator.cityofnewyork.us/sites/default/files/public/Elevator%20and%20Stairwell%20Roof%20Vents.pdf 22 | -------------------------------------------------------------------------------- /proposals/2019/Add None to ControlTechnology.md: -------------------------------------------------------------------------------- 1 | # ControlTechnology - Add "None" Enumeration 2 | 3 | ## Overview 4 | 5 | The `` enumeration does not have a "None" value. 6 | 7 | ## Justification 8 | 9 | There exists a need for certain users to assert that no `` is available. 10 | 11 | The assertion that no `` is available is disjoint to not asserting the `` element. 12 | 13 | ## Implementation 14 | 15 | This proposal is to: 16 | 17 | Add the following enumerations to ``: 18 | * None 19 | 20 | ## References 21 | 22 | n/a 23 | -------------------------------------------------------------------------------- /proposals/2019/Add OccupancyClassification enums.md: -------------------------------------------------------------------------------- 1 | # OccupancyClassification - Add Enumerations 2 | 3 | ## Overview 4 | 5 | The `auc:OccupancyClassification` element is missing enumerations. 6 | 7 | ## Justification 8 | 9 | Specific enumerations are a required input for ASHRAE Standard 211 [1]. 10 | 11 | ## Implementation 12 | 13 | This proposal is to add the following enumerations to the `auc:OccupancyClassification` element: 14 | * "Assembly-Indoor arena" 15 | * "Assembly-Race track" 16 | * "Assembly-Stadium (closed)" 17 | * "Assembly-Stadium (open)" 18 | * "Bar-Nightclub" 19 | * "Education-Adult" 20 | * "Education-Vocational" 21 | * "Health care-Outpatient facility" 22 | * "Lodging-Barracks" 23 | * "Office-Financial" 24 | * "Public safety station-Fire" 25 | * "Public safety station-Police" 26 | * "Recreation-Bowling alley" 27 | * "Recreation-Roller rink" 28 | * "Retail-Automobile dealership" 29 | * "Science park" 30 | * "Zoo" 31 | 32 | ## References 33 | 34 | 1. https://www.ashrae.org/technical-resources/bookstore/standards-180-and-211 35 | -------------------------------------------------------------------------------- /proposals/2019/Add PercentLeasedByOwner to Building.md: -------------------------------------------------------------------------------- 1 | # Building - Add PercentLeasedByOwner 2 | 3 | ## Overview 4 | 5 | Standard 211 requests collection of the percent of building leased. 6 | 7 | ## Justification 8 | 9 | Standard 211 needs a place for PercentLeasedByOwner 10 | 11 | ## Implementation 12 | 13 | Add `//element(*,auc:SiteType)/auc:Buildings/auc:Building/auc:PercentLeasedByOwner` 14 | 15 | ## References 16 | 17 | N/A 18 | -------------------------------------------------------------------------------- /proposals/2019/Add Plant Fields.md: -------------------------------------------------------------------------------- 1 | # Add YearInstalled to Plant Paths 2 | 3 | ## Overview 4 | 5 | There is no YearInstalled field on the CoolingPlant and HeatingPlant paths. 6 | 7 | ## Justification 8 | 9 | There exists a need for users to add YearInstalled on Cooling Plant and Heating Plant paths. For consistency, also add the field to the CondenserPlant path. 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | 1. Add the following path: BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/Plants/CondenserPlants/CondenserPlant/YearInstalled 15 | 16 | 2. Add the following path: BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/Plants/CoolingPlants/CoolingPlant/YearInstalled 17 | 18 | 3. Add the following elements under path BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/Plants/HeatingPlants/HeatingPlant/YearInstalled 19 | 20 | ## References 21 | 22 | N/A 23 | -------------------------------------------------------------------------------- /proposals/2019/Add PlugLoadType enums.md: -------------------------------------------------------------------------------- 1 | # PlugLoadType - Add Enumerations 2 | 3 | ## Overview 4 | 5 | PlugLoadType is missing useful enumerations. 6 | 7 | ## Justification 8 | 9 | There exists a need for certain users to have additional PlugLoadType enumerations: Broadcast antenna, Kitchen equipment, and Signage display. 10 | 11 | Signage display in this case is to accomodate a "Times Square Sign". 12 | 13 | ## Implementation 14 | 15 | This proposal is to: 16 | Add the following enumerations to path: 17 | BuildingSync/Facilities/Facility/Systems/PlugLoads/PlugLoad/PlugLoadType 18 | 19 | 1. Broadcast antenna 20 | 2. Kitchen equipment 21 | 3. Signage display 22 | 23 | ## References 24 | 25 | N/A -------------------------------------------------------------------------------- /proposals/2019/Add PrimaryFuel to HeatingPlantType and CoolingPlantType.md: -------------------------------------------------------------------------------- 1 | # Add PrimaryFuel Element to Heating and Cooling Plants 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `` element to the definitions of the ``, `` and `` elements. 6 | 7 | ## Justification 8 | 9 | Some users need to specify the main fuel used by heating and cooling plants. 10 | 11 | ## Implementation 12 | 13 | Add the `` element to the following XPaths: 14 | 15 | * `BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/Plants/HeatingPlants/HeatingPlant` 16 | * `BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/Plants/CoolingPlants/CoolingPlant` 17 | * `BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/Plants/CoolingPlants/CondenserPlantType` 18 | 19 | ## References 20 | 21 | n/a 22 | -------------------------------------------------------------------------------- /proposals/2019/Add RoofCondition to RoofID Link.md: -------------------------------------------------------------------------------- 1 | # Add RoofCondition to RoofID Link 2 | 3 | ## Overview 4 | 5 | Add `` element to `` element. 6 | 7 | ## Justification 8 | 9 | Currently, there is no way to store the overall condition of a roof system. The RoofCondition is on the link to the RoofSystem allowing for the same roof system to have multiple conditions based on the Section of the building. 10 | 11 | ## Implementation 12 | 13 | Add `` element (of type ``) to the following XPaths: 14 | * `BuildingSync/Facilities/Facility/Sites/Site/Section/Section/Roofs/Roof/RoofID/` 15 | 16 | ## References 17 | 18 | n/a 19 | -------------------------------------------------------------------------------- /proposals/2019/Add Scenario Notes.md: -------------------------------------------------------------------------------- 1 | # Add ScenarioNotes to Scenario 2 | 3 | ## Overview 4 | 5 | Add ScenarioNotes to the Scenario element. 6 | 7 | ## Justification 8 | 9 | There is no current way to store notes related to a scenario without using a user defined field. 10 | 11 | ## Implementation 12 | 13 | Add BuildingSync/Facilities/Facility/Reports/Report/Scenarios/Scenario/ScenarioNotes 14 | 15 | ## References 16 | 17 | N/A 18 | -------------------------------------------------------------------------------- /proposals/2019/Add UDF to PackageOfMeasures.md: -------------------------------------------------------------------------------- 1 | # PackageOfMeasures - Add UserDefinedFields 2 | 3 | ## Overview 4 | 5 | PackageOfMeasures does not have UserDefinedFields. 6 | 7 | ## Justification 8 | 9 | There exists a need for certain users to add user-defined fields on PackageOfMeasures 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | 15 | Add the following elements under BuildingSync/Facilities/Facility/Reports/Report/Scenarios/Scenario/ScenarioType/PackageOfMeasures: 16 | 17 | 1. UserDefinedFields 18 | 2. UserDefinedFields/UserDefinedField 19 | 3. UserDefinedFields/UserDefinedField/FieldName 20 | 4. UserDefinedFields/UserDefinedField/FieldValue 21 | 22 | ## References 23 | 24 | N/A 25 | -------------------------------------------------------------------------------- /proposals/2019/Add YearBurnerInstalled.md: -------------------------------------------------------------------------------- 1 | # Add YearBurnerInstalled 2 | 3 | ## Overview 4 | 5 | There is no year burner installed field on Boiler and Furnace paths. 6 | 7 | ## Justification 8 | 9 | There exists a need for users to add year burner installed on the burner path, which is found under both Boiler and Furnace. 10 | 11 | ## Implementation 12 | 13 | The proposed name of the element has been updated to BurnerYearInstalled to allow for grouping of the Burner elements. 14 | 15 | This proposal is to: 16 | 1. Add the following path: 17 | BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/HeatingAndCoolingSystems/HeatingSources/HeatingSource/HeatingSourceType/Furnace/BurnerYearInstalled 18 | 19 | 2. Add the following path: 20 | BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/Plants/HeatingPlants/HeatingPlant/Boiler/BurnerYearInstalled 21 | 22 | ## References 23 | 24 | N/A 25 | -------------------------------------------------------------------------------- /proposals/2019/Add to Measure Scale of Application.md: -------------------------------------------------------------------------------- 1 | # MeasureScaleOfApplication - Add Enumerations 2 | 3 | ## Overview 4 | 5 | The `auc:MeasureScaleOfApplication` element does not have enumerations for common areas and tenant areas. 6 | 7 | ## Justification 8 | 9 | In Audit Template, for each measure, the affected portions of the building are identified as being either: 10 | * Common areas, 11 | * Tenant areas, or 12 | * Entire building. 13 | 14 | Currently, only "Entire building" is supported in BuildingSync XML. 15 | 16 | ## Implementation 17 | 18 | This proposal is to add the following enumeration values to the `auc:MeasureScaleOfApplication` element: 19 | * "Common areas" 20 | * "Tenant areas" 21 | 22 | ## References 23 | 24 | n/a 25 | -------------------------------------------------------------------------------- /proposals/2019/Address on Buildings.md: -------------------------------------------------------------------------------- 1 | # Add the Address Element to a Building 2 | 3 | ## Overview 4 | 5 | The release of Version 1.0 added the concept of a building to the schema; however, the building element does not have the concept of an address. The parent element, Site, does contain an address element 6 | 7 | ## Justification 8 | 9 | The need to have two addresses is logical when dealing with campuses. In the campus use case, a Site can have an address (the contact/mailing address) and each building in the campus can have another address. 10 | 11 | If there is only one site and one building, then it is at the user discretion to select which address to fill out. It is encouraged to verify with the Use Case Selection Tool which fields are required based on the BuildingSync use case. It is also recommended to use the higher level address over the building level address element. 12 | 13 | 14 | ## Implementation 15 | 16 | This proposal is to: 17 | 1. Add BuildingSync/Facilities/Facility/Sites/Site/Buildings/Building/Address element. 18 | 2. The address element references the global Address element. 19 | 20 | ## References 21 | 22 | N/A 23 | -------------------------------------------------------------------------------- /proposals/2019/Audit Date Enumerations.md: -------------------------------------------------------------------------------- 1 | # Add List of Audit Dates and Enumerations 2 | 3 | ## Overview 4 | 5 | There are several dates that are of interest during an audit such as the site visit, the completion of the audit, and perhaps others. The current path to the Audit Date is BuildingSync/Facilities/Facility/Reports/Report/AuditDate. This field is defined as just the date the audit was conducted. 6 | 7 | 8 | ## Justification 9 | 10 | The schema needs to be extended to store several dates related to audits. 11 | 12 | ## Implementation 13 | 14 | Add a new paired element container to store multiple dates for any report. 15 | 16 | New container will be `BuildingSync/Facilities/Facility/Reports/Report/AuditDates/AuditDate`. 17 | 18 | The existing enumerations being proposed are: 19 | 20 | ```xml 21 | 22 | 23 | 24 | ``` 25 | 26 | This is a breaking change. 27 | 28 | ## References 29 | 30 | N/A 31 | 32 | -------------------------------------------------------------------------------- /proposals/2019/BRICR Support.md: -------------------------------------------------------------------------------- 1 | # BRICR Support 2 | 3 | ## Overview 4 | 5 | Add fields to CalculationMethod, Measure, and ResourceUses to support the BRICR Use Case. 6 | 7 | ## Justification 8 | 9 | There exists a need to have additional fields added to the schema to support BRICR: 10 | 11 | 1. Adding WeatherDataType and SimulationCompletionStatus to CalculationMethod, which is referenced in multipled places in the schema (i.e., BuildingSync/Facilities/Facility/Reports/Report/Scenarios/Scenario/ScenarioType/PackageOfMeasures/CalculationMethod) 12 | 13 | 1. Adding CustomMeasureName to Measure element, in order to capture the OpenStudioMeasureName. 14 | 15 | 1. Add AnnualPeakNativeUnits and AnnualPeakConsistentUnits under ResourceUses. ConsistentUnits are set at: kW. 16 | 17 | ## Implementation 18 | 19 | This proposal is to: 20 | 21 | 1. Add WeatherDataType (with enums: 'Typical Meteorological Year' and 'Weather Station') to the CalculationMethod element. 22 | 23 | 1. Add SimulationCompletionStatus (with enums: 'Not Started', 'Started', 'Queued', 'Finished', 'Other', 'Unknown') to the CalculationMethod element. 24 | 25 | 1. Add CustomMeasureName element under Measure path: BuildingSync/Facilities/Facility/Measures/Measure. 26 | 27 | 1. Add AnnualPeakNativeUnits and AnnualPeakConsistentUnits under BuildingSync/Facilities/Facility/Reports/Report/Scenarios/Scenario/ResourceUses. 28 | 29 | 30 | ## References 31 | 32 | N/A 33 | -------------------------------------------------------------------------------- /proposals/2019/Ballast Type Enums.md: -------------------------------------------------------------------------------- 1 | # Add Enums to ballastType 2 | 3 | ## Overview 4 | 5 | enumeration does not distinguish between “Standard Electronic” and “Premium Electronic” values (both are mapped to “Electronic”). 6 | 7 | ## Justification 8 | 9 | There exists a need for certain users to differentiate between Standard Electronic and Premium Electronic for ballast type. THIS IS A BREAKING CHANGE. 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | 15 | Remove 'Electronic' 16 | Add 'Standard Electronic' 17 | Add 'Premium Electronic' 18 | 19 | enums to: 20 | BuildingSync/Facilities/Facility/Systems/LightingSystems/LightingSystem/BallastType 21 | 22 | ## References 23 | 24 | N/A 25 | -------------------------------------------------------------------------------- /proposals/2019/Blue Roof.md: -------------------------------------------------------------------------------- 1 | # Add Blue Roof to SpecialRoofClassification 2 | 3 | ## Overview 4 | 5 | The schema needs to be extended to allow for Blue Roof classification. 6 | 7 | ```xml 8 | 9 | 10 | 11 | ``` 12 | 13 | 14 | ## Justification 15 | 16 | 17 | For Local Law 87 the auditor is able to select a Blue Roof. There needs to exist a place in the schema for this request as it is expected to expand beyond the scope of LL87. 18 | 19 | 20 | ## Implementation 21 | 22 | Add the following to the SpecialRoofClassification located at `BuildingSync/Facilities/Facility/Systems/RoofSystems/RoofSystem/SpecialRoofClassification` 23 | 24 | ```xml 25 | 26 | ``` 27 | 28 | ## References 29 | 30 | N/A 31 | 32 | -------------------------------------------------------------------------------- /proposals/2019/Change Audit to Project.md: -------------------------------------------------------------------------------- 1 | # Changes to Support Other Project Types # 2 | 3 | ## Overview ## 4 | The BuildingSync schema can be useful and leveraged for more types of project than just audits, and the current schema uses an audit element that can be confusing. After changing the root element to not be Audit, this proposal will add information to help identify the BuildingSync instance. 5 | 6 | ## Justification ## 7 | A few relatively small changes are proposed to better support other cases. The proposed BuildingSync element names have been reviewed by LBNL BEDES team so that they use BEDES compliant terms and structure. 8 | 9 | ## Implementation ## 10 | The proposed implementation is to add the elements marked with a '*' to the BuildingSync.xsd code: 11 | >BuildingSync/ 12 | oPrograms/* 13 | -Program/* 14 | +ProgramDate* 15 | +ProgramFundingSource* 16 | +ProgramClassification* 17 | oFacilities/Facility/ 18 | Note that this root element sequence refers to the one explained in Proposal #64. 19 | 20 | Steps: 21 | a)Create an element named 'Programs' as a sibling of 'Facility.' 22 | b)Create an element named 'Program' as a child of 'Programs.' 23 | c)Create the elements 'ProgramDate,' 'ProgramFundingSource,' and 'Program Classification' as children of 'Program.' 24 | d)Add the BEDES definition of each BEDES term used as a description of the mentioned elements. 25 | 26 | 27 | ## References ## 28 | Site used to research BEDES terms: https://bedes.lbl.gov/bedes-online -------------------------------------------------------------------------------- /proposals/2019/Consolidate MELs and Plug Loads.md: -------------------------------------------------------------------------------- 1 | # Consolidate MEL and Plug Load Elements 2 | 3 | ## Overview 4 | The current schema has MELs and plug loads in the same list and uses the name `PlugLoadType` twice. This proposal consolidates the two types and renames the XML type so there is no repeated use. This is a breaking change. 5 | 6 | ## Justification 7 | The current organization is not consistent with the rest of the schema and the repeated use of the name trips up some automatic processors. 8 | 9 | ## Implementation 10 | The XSD complex type `PlugLoadType` will be renamed to `PlugElectricLoadType`, which eliminates the double use of `PlugLoadType`. This is not a breaking change because the XSD type is not visible to the user in this case. 11 | 12 | Next, two changes will be made to `PlugElectricLoadType` so that the information that was previously represented by the `MiscellaneousElectricLoad` element can be fully represented. 13 | 14 | 1. Add an element to represent weighted average electric loads in W/ft2 15 | 2. Add `Miscellaneous Electric Load` to the `PlugLoadType` enumeration 16 | 17 | Finally, the `MiscellaneousElectricLoad` element will be removed. This is a breaking change. 18 | -------------------------------------------------------------------------------- /proposals/2019/Consolidate Misc Gas Loads.md: -------------------------------------------------------------------------------- 1 | # Consolidate Miscellaneous Gas Loads 2 | 3 | ## Overview 4 | The current schema has miscellaneous gas loads and process loads in the same list and uses the name `ProcessLoadType` twice. This proposal consolidates the two types and renames the XML type so there is no repeated use. This is a breaking change. 5 | 6 | ## Justification 7 | The current organization is not consistent with the rest of the schema and the repeated use of the name trips up some automatic processors. 8 | 9 | ## Implementation 10 | The following changes will be made to `ProcessLoadType` so that the information that was previously represented by the `MiscellaneousGasLoad` element can be fully represented. 11 | 12 | 1. The XSD complex type `ProcessLoadType` will be renamed to `ProcessGasElecLoadType`, which eliminates the double use of `ProcessLoadType`. This is not a breaking change because the XSD type is not visible to the user in this case. 13 | 2. Add an element to represent weighted average process loads in W/ft2. Note that the previous miscellaneous gas load element was represented in kBtu/ft2 and we are proposing to change it to W/ft2 to stay consistent with other elements in the `ProcessGasElecLoadType`. 14 | 3. Add `Miscellaneous Gas Load` to the `ProcessLoadType` enumeration, 15 | 4. Add `Source` attributes to both the `PlugLoadType` and `ProcessGasElecLoadType` 16 | 17 | The `MiscellaneousGasLoad` element will be removed. This is a breaking change. 18 | -------------------------------------------------------------------------------- /proposals/2019/Contact Roles.md: -------------------------------------------------------------------------------- 1 | # Multiple ContactRoles for Contact 2 | 3 | ## Overview 4 | 5 | If the same contact has multiple roles, then the entire contact has to be duplicated. Also, there needs to be a submitter as a contact role. The current list of contact roles is the following: 6 | 7 | ```xml 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | ``` 49 | 50 | ## Justification 51 | 52 | A contact should be able to have multiple roles. 53 | 54 | 55 | ## Implementation 56 | 57 | There are two changes that are proposed. 58 | 59 | 1. ContactRole under ContactType `//element(*,auc:ContactType)/auc:ContactRole` will be moved under a new container objective called ContactRoles and made unbounded. 60 | 61 | 2. A new enumeration will be added to support the role of an audit submitter. This is a non-breaking change. 62 | ```xml 63 | 64 | ``` 65 | 66 | ## References 67 | 68 | N/A 69 | 70 | -------------------------------------------------------------------------------- /proposals/2019/Enable Multiple Reports.md: -------------------------------------------------------------------------------- 1 | # Enable Multiple Reports in a Single BuildingSync XML Data 2 | 3 | ## Overview 4 | At present, BuildingSync allows only a single report in valid XML data. This proposal will expand the schema to allow for multiple reports and will make the necessary additions to the Report type to facilitate this change. The changes are breaking. 5 | 6 | ## Justification 7 | A single report per file limits the extent to which reports can be associated with different parts of buildings or systems. This is particularly an issue when data has been collected for part of a building, but the report implicitly applies to all buildings in the file. Furthermore, BuildingSync should be able to track changes over time, and allowing multiple reports means that this will be easier to do. Users can simply add a new report if another audit is done rather than add to previous data. While this isn't strictly necessary, it is a slightly more natural representation and should be easier on users. 8 | 9 | ## Implementation 10 | Three steps will be taken to make this change: 11 | 12 | 1. The report element will be changed into a containerized list: ``. 13 | 2. Building off of the `LinkedPremises` type, create a linkage type that allows users to specify that the report applies to a premises or a system. It is possible that a union type will accomplish this. 14 | 3. Modify the example files to use the containerized lists of reporting. 15 | 16 | Step 2 is not breaking changes, but step 1 is. If we are rigidly following semantic versioning, at the completion of this modification the version number of the schema will need to be bumped to 2.0. 17 | -------------------------------------------------------------------------------- /proposals/2019/Enable Multiple Special Roof Classifications.md: -------------------------------------------------------------------------------- 1 | # Enable Multiple Special Roof Classifications 2 | 3 | ## Overview 4 | 5 | This proposal is to allow multiple ``. 6 | 7 | ## Justification 8 | 9 | Special roof classifications are not mutually exclusive [1]. 10 | 11 | ## Implementation 12 | 13 | This proposal is to add the following paths with annotations from BEDES: 14 | * `//BuildingSync/Facilities/Facility/Systems/RoofSystems/RoofSystem/BlueRoof` 15 | * `//BuildingSync/Facilities/Facility/Systems/RoofSystems/RoofSystem/CoolRoof` 16 | * `//BuildingSync/Facilities/Facility/Systems/RoofSystems/RoofSystem/GreenRoof` 17 | 18 | ## References 19 | 20 | 1. "Sustainable Roofs | Miami Beach - Rising Above". Accessed at: 2019/06/28. Available at: http://www.mbrisingabove.com/climate-adaptation/green-infrastructure/roofs/. 21 | -------------------------------------------------------------------------------- /proposals/2019/Harmonize Tightness and TightnessFitCondition elements.md: -------------------------------------------------------------------------------- 1 | # Harmonize Tightness and TightnessFitCondition elements 2 | 3 | ## Overview 4 | 5 | The enumerations for the `auc:Tightness` and `auc:TightnessFitCondition` elements are very similar (one uses the term "Leaky"; whereas, the other uses the term "Loose"). 6 | 7 | The `auc:Tightness` element is strictly more expressive, since it includes "Very Tight" and "Very Leaky" enumerations. 8 | 9 | ## Justification 10 | 11 | Adding the enumerations "Very Tight" and "Very Loose" to the `auc:TightnessFitCondition` element introduces unnecessary redundancy. 12 | 13 | ## Implementation 14 | 15 | This proposal is to: 16 | * Reify the `auc:Tightness` enumeration into a new `xs:simpleType`. 17 | * Modify the definitions of the `auc:Tightness` and `auc:TightnessFitCondition` elements to reuse the new `auc:Tightness` enumeration. 18 | 19 | This is a breaking change. 20 | Occurrences of "Loose" in the `auc:TightnessFitCondition` element must be replaced with "Leaky". 21 | 22 | ## References 23 | 24 | n/a 25 | -------------------------------------------------------------------------------- /proposals/2019/IDREF Proposal Justification.md: -------------------------------------------------------------------------------- 1 | # Justification of IDREF Updates 2 | 3 | ## Definition of "IDREFs" 4 | 5 | These letters, whether lower or uppercase, only appear in three ways within the BuildingSync.xsd schema file. They are either the value of an attribute's name, the value of an attribute's type, or the value of an extension's base: 6 | 7 | ```xml 8 | 9 | ``` 10 | 11 | In this case, the marked "IDref" refers to the value of the attribute's name. The W3C has no standard specifications for whether an attribute's name should contain lowercase or uppercase letters. As long as this name contains alphanumeric characters and it does not start with a number, it is up to standard. Therefore, "IDref" is an acceptable string to use as the value of an attribute's name according to W3C standards. 12 | 13 | ```xml 14 | 15 | ``` 16 | 17 | In this case, the marked "xs:IDREF" refers to the value of the attribute's type (data type). According to W3C standard specifications, the "xs:" portion of an attribute's type value must be stated in lowercase letters and the "IDREF" portion must contain only uppercase letters. Therefore, "xs:IDREF" is the correct string to use as the value of an attribute's type according to W3C standards. 18 | 19 | ```xml 20 | 21 | ``` 22 | 23 | In this case, the marked "xs:IDREF" refers to the value of the extension's base. The value of this base can be the name of a built-in data type, a simpleType element, or a complexType element; in this case, the base value is a data type. According to W3C standard specifications, the "xs:" portion of an extension's data type value must be stated in lowercase letters and the "IDREF" portion must contain only uppercase letters. Therefore, "xs:IDREF" is the correct string to use as the value of an extension's data type according to W3C standards. 24 | 25 | ## Recommendation 26 | 27 | The BuildingSync schema is already complete without the need for a Proposal and its related work. 28 | 29 | ## Justification 30 | 31 | All IDREF instances-either as `name="IDref"`, `type="xs:IDREF"`, or `base="xs:IDREF"`-are consistent throughout the whole BuildingSync.xsd document as it stands before any work is performed on it by PSD. All instances are cased consistently, following W3C standards; therefore, there is no work needed in order to make the schema compliant. Furthermore, since no modifications to the BuildingSync schema are required, there is no need for a proposal to be submitted for this task. 32 | -------------------------------------------------------------------------------- /proposals/2019/IDREF Proposal.md: -------------------------------------------------------------------------------- 1 | # Ensure all "IDREF" are consistent and W3C compliant 2 | 3 | ## Overview 4 | 5 | The BuildingSync.xsd document includes several instances of values with the "IDREF" string. It is hereby proposed these instances be checked to ensure they are: 6 | 7 | * Compliant with the W3C Recommendation pertaining to XML Schemas, i.e., "W3C compliant." 8 | * Consistent throughout the schema document. 9 | 10 | 11 | ## Justification 12 | 13 | The BuildingSync XML schema must be W3C compliant to provide satisfactory performance and portability across systems. It must also be consistent to ensure proper code execution and facilitate future code review and possible modifications. 14 | 15 | 16 | ## Implementation 17 | 18 | The following non-breaking changes must take place in the BuildingSync.xsd document: 19 | 20 | 1. Find all occurrences of the string "IDREF." Include occurrences where some/all letters are lowercase. 21 | 2. Group occurrences based on their code statement’s tag type (e.g., element, attribute, extension, etc.) and tag attribute type (e.g., type, base, name, etc.). 22 | 3. Research the W3C standards that apply to each occurrence "group." 23 | 4. If any occurrence is not W3C compliant, rename it according to W3C XML standards. 24 | 5. If any occurrence is not consistent with other occurrences of the same type, rename it to ensure consistency. Maintain W3C compliance. 25 | 26 | ## References 27 | 28 | More information on W3C XML schema standards can be found here: https://www.w3schools.com/xml/ 29 | 30 | -------------------------------------------------------------------------------- /proposals/2019/Linear Fluorescent Enumeration.md: -------------------------------------------------------------------------------- 1 | # Linear Fluorescent Enumeration 2 | 3 | ## Overview 4 | 5 | There are no T12 High Output lighting fixtures 6 | 7 | ## Justification 8 | 9 | T12 High Output lighting systems exist and need to be added. Current enumerations at BuildingSync/Facilities/Facility/Systems/LightingSystems/LightingSystem/LampType/LinearFluorescent/LampLabel are: 10 | 11 | ```xml 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | ``` 22 | 23 | ## Implementation 24 | 25 | The new elements will be: 26 | 27 | ```xml 28 | 29 | ``` 30 | 31 | ## References 32 | 33 | https://www.lightbulbsdirect.com/t12ho 34 | 35 | -------------------------------------------------------------------------------- /proposals/2019/Make FanBased Optional.md: -------------------------------------------------------------------------------- 1 | # Make FanBased ZoneEquipment Optional 2 | 3 | ## Overview 4 | 5 | The fan based zone equipment object was set to be required. If a building has only radiant panels, then this requirement is not necessary. 6 | 7 | ## Justification 8 | 9 | A user needs to be able to specify a radiant system without a fan based system 10 | 11 | ## Implementation 12 | 13 | Add `minOccurs="0"` to FanBasedType 14 | 15 | This is a non-breaking change. 16 | 17 | ## References 18 | 19 | N/A 20 | 21 | -------------------------------------------------------------------------------- /proposals/2019/Modify DaylightingIlluminanceSetpoint units.md: -------------------------------------------------------------------------------- 1 | # Modify DaylightingIlluminanceSetpoint Units 2 | 3 | ## Overview 4 | 5 | The units of measure for the `auc:DaylightingIlluminanceSetpoint` should be foot-candles (not lux). 6 | 7 | ## Justification 8 | 9 | [1] 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | 1. Modify the documentation string for the `auc:DaylightingIlluminanceSetpoint` element. 15 | 2. Update the example files. 16 | 17 | ## References 18 | 19 | 1. https://www.lightingdesignlab.com/sites/default/files/pdf/Footcandle_Lighting%20Guide_Rev.072013.pdf 20 | -------------------------------------------------------------------------------- /proposals/2019/Multiple Roofs Foundations Ceilings.md: -------------------------------------------------------------------------------- 1 | # Allow Multiple Roofs, Foundations, and Ceilings on Section 2 | 3 | ## Overview 4 | 5 | A section is allowed to only have a single reference of RoofID, CeilingID, and FoundationID. This causes issues when there may be more than one roof/ceiling/foundation in a section. 6 | 7 | ## Justification 8 | 9 | Audit Template Tool allows for a list of roofs, ceilings, and foundations, however, there is no easy way to reference these multiple constructions in the Sites/Building path. 10 | 11 | ## Implementation 12 | 13 | Create containers for Roofs, Ceilings, and Foundations similar to the Sides element at `//BuildingSync/Facilities/Facility/Sites/Site/Buildings/Building/Sections/Section/Sides`. 14 | 15 | * Move `//element(*:BuildingType)/Sections/Section/RoofID` under `//element(*:BuildingType)/Sections/Section/Roofs/Roof`. Make `Roof` unbounded. 16 | * Move `//element(*:BuildingType)/Sections/Section/CeilingID` under `//element(*:BuildingType)/Sections/Section/Ceilings/Ceiling`. Make `Ceiling` unbounded. 17 | * Move `//element(*:BuildingType)/Sections/Section/FoundationID` under `//element(*:BuildingType)/Sections/Section/Foundations/Foundation`. Make `Foundation` unbounded. 18 | 19 | ## References 20 | 21 | N/A 22 | -------------------------------------------------------------------------------- /proposals/2019/OccupancyClassification.md: -------------------------------------------------------------------------------- 1 | # OccupancyClassification - Add Enumerations 2 | 3 | ## Overview 4 | 5 | enumeration does not have “Trading floor” or “TV studio” values. 6 | 7 | ## Justification 8 | 9 | There exists a need for certain users to have additional enumerations added to OccupancyClassification. 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | Add the following enumerations to OccupancyClassification: 15 | Trading floor 16 | TV studio 17 | 18 | ## References 19 | 20 | N/A 21 | -------------------------------------------------------------------------------- /proposals/2019/OtherEnergyGenerationTechnology.md: -------------------------------------------------------------------------------- 1 | # OtherEnergyGenerationTechnology - Add Enumeration 2 | 3 | ## Overview 4 | 5 | OtherEnergyGenerationTechnology enumeration does not have “Reciprocating engine". 6 | 7 | ## Justification 8 | 9 | There exists a need for certain users to have an additional enumeration. 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | Add the enumeration "Reciprocating engine" to the path 15 | BuildingSync/Facilities/Facility/Systems/OnSiteStorageTransmissionGenerationSystems/OnSiteStorageTransmissionGenerationSystem/EnergyConversionType/Generation/OnSiteGenerationType/Other/OtherEnergyGenerationTechnology 16 | 17 | ## References 18 | 19 | N/A 20 | -------------------------------------------------------------------------------- /proposals/2019/Ownership Enumeration.md: -------------------------------------------------------------------------------- 1 | # Ownership Enumeration 2 | 3 | ## Overview 4 | 5 | There are a few new Ownership enumerations that have been requested. 6 | 7 | ## Justification 8 | 9 | There are two new items that are proposed. The current list is the following: 10 | 11 | ```xml 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | ``` 25 | 26 | ## Implementation 27 | 28 | The new elements will be: 29 | 30 | ```xml 31 | 32 | 33 | ``` 34 | 35 | ## References 36 | 37 | N/A 38 | 39 | -------------------------------------------------------------------------------- /proposals/2019/Package of Measures ID.md: -------------------------------------------------------------------------------- 1 | # PackageOfMeasures ID 2 | 3 | ## Overview 4 | 5 | Add an ID to PackageOfMeasures 6 | 7 | ## Justification 8 | 9 | Allow for an ID on the PackageOfMeasures 10 | 11 | ## Implementation 12 | 13 | Add an @ID attribute on BuildingSync/Facilities/Facility/Reports/Report/Scenarios/Scenario/ScenarioType/PackageOfMeasures 14 | 15 | ## References 16 | 17 | N/A 18 | 19 | -------------------------------------------------------------------------------- /proposals/2019/Plant and Source Location.md: -------------------------------------------------------------------------------- 1 | # Add Location Element to Plants and Heating/Cooling Sources 2 | 3 | ## Overview 4 | 5 | HVACSystem Plant and Sources do not have a location specifier. For example if a cooling source (e.g. PTZ, RTU), then there needs to be a way to specify where the system is located such as the Roof. 6 | 7 | ## Justification 8 | 9 | The location of the plant and heating/cooling sources needs to be defined. 10 | 11 | ## Implementation 12 | 13 | Add the `Location` to the following paths: 14 | 15 | * BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/HeatingAndCoolingSystems/CoolingSources/CoolingSource 16 | * BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/HeatingAndCoolingSystems/HeatingSources/HeatingSource 17 | * BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/Plants/HeatingPlants/HeatingPlant 18 | * BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/Plants/CoolingPlants/CoolingPlant 19 | * BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/Plants/CondenserPlants/CondenserPlant 20 | 21 | ## References 22 | 23 | N/A 24 | -------------------------------------------------------------------------------- /proposals/2019/Pluralize ControlSystemType element in Plants.md: -------------------------------------------------------------------------------- 1 | # ControlSystemType - Pluralize 2 | 3 | ## Overview 4 | 5 | Pluralize the `auc:ControlSystemType` element for `auc:HeatingPlant`, `auc:CoolingPlant` and `auc:CondenserPlant` elements. 6 | 7 | ## Justification 8 | 9 | In Audit Template, it is possible for plant equipment to have multiple control strategies, e.g., heating plant equipment may have either/both digital and/or pneumatic-based control strategies. 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | 15 | 1. Add the `auc:ControlSystemTypes` element to the `auc:HeatingPlant`, `auc:CoolingPlant` and `auc:CondenserPlant` elements. 16 | 17 | 2. Move the singular `auc:ControlSystemType` element to the new `auc:ControlSystemTypes` elements. 18 | 19 | ## References 20 | 21 | n/a 22 | -------------------------------------------------------------------------------- /proposals/2019/Pluralize LinkedDeliveryID.md: -------------------------------------------------------------------------------- 1 | # LinkedDeliveryID - Pluralize 2 | 3 | ## Overview 4 | 5 | Pluralize the `auc:LinkedDeliveryID` element. 6 | 7 | ## Justification 8 | 9 | In Audit Template, it is possible for an HVAC system to service multiple delivery mechanisms, e.g., zone equipment and central air distribution. 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | 15 | 1. Add `auc:LinkedDeliveryIDs` element to the `auc:OtherHVACSystemType` element. 16 | 17 | 2. Make `auc:LinkedDeliveryID` element and child element of the new `auc:LinkedDeliveryIDs` element. 18 | 19 | ## References 20 | 21 | n/a 22 | -------------------------------------------------------------------------------- /proposals/2019/Pluralize PrimaryHVACControlSystemType.md: -------------------------------------------------------------------------------- 1 | # PrimaryHVACControlSystemType - Pluralize 2 | 3 | ## Overview 4 | 5 | Pluralize the `auc:PrimaryHVACControlSystemType` element. 6 | 7 | ## Justification 8 | 9 | In Audit Template, it is possible for HVAC equipment to have multiple control strategies. 10 | 11 | ## Implementation 12 | 13 | This proposal is to: 14 | 15 | 1. Rename the `auc:PrimaryHVACControlSystemType` element to `auc:HVACControlSystemType`. 16 | 17 | 2. Add the `auc:HVACControlSystemTypes` element to the `auc:HVACSystemType` element. 18 | 19 | 2. Move the renamed `auc:HVACControlSystemType` to the new `auc:HVACControlSystemTypes` element. 20 | 21 | ## References 22 | 23 | n/a 24 | -------------------------------------------------------------------------------- /proposals/2019/Qualifications List V2.md: -------------------------------------------------------------------------------- 1 | # Update the Qualifications List 2 | 3 | ## Overview 4 | 5 | There are new auditor qualifications that need to be added. Current list is the following: 6 | 7 | ```xml 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | ``` 38 | 39 | ## Justification 40 | 41 | The list of qualified auditors is expected to have additions over time as more organizations see the value in performing building energy audits. The changes only include minor additions. 42 | 43 | ## Implementation 44 | 45 | This proposal is to add the following: 46 | 47 | ```xml 48 | 49 | 50 | 51 | 52 | 53 | 54 | ``` 55 | 56 | ## References 57 | 58 | N/A 59 | -------------------------------------------------------------------------------- /proposals/2019/Rename GasElec to GasElectric.md: -------------------------------------------------------------------------------- 1 | # Rename ProcessGasElecLoadType Element 2 | 3 | ## Overview 4 | 5 | Rename the `auc:ProcessGasElecLoadType` element to `auc:ProcessGasElectricLoadType`. 6 | 7 | ## Justification 8 | 9 | The term `ProcessGasElecLoadType` is inconsistent with the term `PlugElectricLoadType`. 10 | In the former, the term "Electric" is abbreviated to "Elec", where in the latter, it is not. 11 | 12 | ## Implementation 13 | 14 | This proposal is to rename the `auc:ProcessGasElecLoadType` element to `auc:ProcessGasElectricLoadType`. 15 | 16 | ## References 17 | 18 | n/a 19 | -------------------------------------------------------------------------------- /proposals/2019/Rename OnSite to Onsite.md: -------------------------------------------------------------------------------- 1 | # Rename OnSite and On-site to Onsite 2 | 3 | ## Overview 4 | 5 | It was discovered that we are inconsistently using OnSite, On-site, and Onsite. 6 | 7 | ## Justification 8 | 9 | There is a general need to keep BuildingSync consistent and this needs to be addressed. These will be breaking changes. 10 | 11 | ## Implementation 12 | 13 | Rename elements that have OnSite to Onsite. This follows the BEDES definition of Onsite. 14 | 15 | This impacts the following paths: 16 | 17 | * BuildingSync/Facilities/Facility/Systems/OnsiteStorageTransmissionGenerationSystems/OnsiteStorageTransmissionGenerationSystem 18 | * BuildingSync/Facilities/Facility/Systems/OnsiteStorageTransmissionGenerationSystems/OnsiteStorageTransmissionGenerationSystem/EnergyConversionType/Generation/OnsiteGenerationType 19 | * Enum in auc:BuildingSync/auc:Facilities/auc:Facility/auc:Measures/auc:Measure/auc:SystemCategoryAffected 20 | * Enum in auc:BuildingSync/auc:Facilities/auc:Facility/auc:Measures/auc:Measure/auc:TechnologyCategories/auc:TechnologyCategory/auc:WaterAndSewerConservationSystems/auc:MeasureName 21 | * Various annotations 22 | 23 | ## References 24 | 25 | https://bedes.lbl.gov/bedes-online/onsite 26 | -------------------------------------------------------------------------------- /proposals/2019/Rename Root Element.md: -------------------------------------------------------------------------------- 1 | # Rename the Root Element 2 | 3 | ## Overview 4 | 5 | Presently, the root element of the BuildingSync schema is Audit. Having the root element as Audit limits the scope of 6 | BuildingSync to 'projects' that are audits, assuming the user does not want to confuse the consumer for 'projects' that 7 | are non-audits. In addition, the existing schema is designed to allow multiple audits in a single instance. 8 | 9 | There exist several use cases where BuildingSync should be used even though the overall 'project' was not a ASHRAE 10 | Standard 211-type audit. For example: 11 | 12 | 1) exporting building from Asset Score 13 | 2) generating a hypothetical building for use in advanced workflows (e.g. simulations) 14 | 3) no touch audits which may not be classified as an ASHRAE Standard 211 audit 15 | 4) transferring building data for use in M&V IPMVP Option C/D type analysis 16 | 5) exporting a benchmarking building from SEED. 17 | 18 | Existing root sequence for BuildingSync is `Audits/Audit/Sites/Site/Facilities/Facility/` 19 | 20 | ## Justification 21 | 22 | As described in the Overview, the use cases of BuildingSync is easily extended past the commonly defined audit-based schema. 23 | Traditionally, the root element of an XML schema is a term used to define the data that will be described in detail. With this in 24 | mind, the existing root element of Audits means that the schema is defining an Audit (which is partly true); however, this schema is 25 | more reallistically defining a Building (or Facility). Also, based on other commonly used schemas, the root element is often 26 | named the same as the schema (e.g. HPXML root element is `HPXML`, gbXML root element is `gbXML`); therefore, the root element in 27 | this implementation could/should be `BuildingSync`. 28 | 29 | 30 | ## Implementation 31 | 32 | The proposed implementation is to rename the root element sequence in the BuildingSync.xsd file from `Audits/Audit/Sites/Site/Facilities/Facility` to `BuildingSync/Campuses/Campus/Sites/Site/Buildings/Building`. The new format can be seen hierarchically below: 33 | 34 | * BuildingSync/ (New) 35 | * Campuses/Campus/ (Previously `Audit`) 36 | * Sites/Site/ (Unchanged) 37 | * Buildings/Building (Previously `Facility`) 38 | 39 | *Note: Multiple options for the name of these elements (Campuses/Campus) have been proposed with the intent of finding the most appropriate term while remaining BEDES compliant. The options are:* 40 | 41 | 1. Campuses/Campus/ 42 | 2. Premises/PremisesIdentifer/ 43 | 3. Facilities/Facility/ 44 | 45 | If you are reviewing, please comment on the preferred version in a comment (enter either '1,' '2,' or '3'). 46 | 47 | Implementation Steps: 48 | 49 | 1. Create an element named `BuildingSync` as a parent of the `Audits` element. 50 | 2. Change the name of the `Audits` and `Audit` elements to `Campuses` and `Campus` (or the chosen term, if different). 51 | 3. Change the name of the `Facilities` and `Facility` elements to `Buildings` and `Building`. 52 | 4. Change the name of the `FacilityClassication` to `BuildingClassification`. Update annotations to replace facility with building. 53 | 5. Add the BEDES definition of each BEDES term used as a description of the mentioned elements. 54 | 55 | 56 | ## Questions 57 | 58 | * Should there exist a new element to define the purpose of the file (e.g. audit, M&V, etc)? Does this already exist? 59 | * It is unclear if Building is an applicable BEDES term. 60 | 61 | 62 | ## References 63 | 64 | N/A -------------------------------------------------------------------------------- /proposals/2019/Rename Subsection to Section.md: -------------------------------------------------------------------------------- 1 | # Rename Subsection to Section 2 | 3 | ## Overview 4 | 5 | This proposal renames the Subsections/Subsection child element of Building to Sections/Section and adds an enumeration to clarify what the section represents. 6 | 7 | ## Justification 8 | 9 | Presently, the schema uses "subsection" terminology that users have found confusing. With no "section" in the schema, it is unclear what is meant. 10 | This change will clarify the meaning of section and allow users to express the intent of the section. 11 | 12 | ## Implementation 13 | 14 | The Subsections/Subsection child element of Building will be renamed to Sections/Section, and a new enumeration called SectionType will be added with the following values: 15 | 16 | * Whole Building: the section describes the whole building 17 | * Space Function: the section describes a space function (see ASHRAE standard 211) 18 | * Component: the section describes a subspace of a primary premises. Examples of components are: HVAC zones, retail shops in a mall, floors in a multi-story building, etc. (BEDES) 19 | * Tenant: the section is defined as a section for a tenant. 20 | * Virtual: the section is loosely defined and may overlap with others 21 | * Other: the section is not well-described by any of the other types 22 | 23 | The original idea included a "Custom" value, but that has been dropped in favor of adding more values. 24 | 25 | The Section elements do not have to be mutually exclusive, for example, there can be a Section describing the whole building and another Section describing the Space Function of a portion of the building. For example, this change allows for geometry (FloorShape) to be described for a whole building section and for a space function. 26 | 27 | ## References 28 | 29 | * https://bedes.lbl.gov/bedes-online/premises-level 30 | * https://bedes.lbl.gov/bedes-online/spatial-unit-type 31 | -------------------------------------------------------------------------------- /proposals/2019/Replicate Site Elements in Building Element.md: -------------------------------------------------------------------------------- 1 | # Replicate Site Elements in Building Element 2 | 3 | ## Overview 4 | 5 | Replicate certain child elements of the `auc:SiteType` element in the `auc:BuildingType` element. 6 | 7 | ## Justification 8 | 9 | In Audit Template, users may submit audits for individual buildings and/or multi-building, New York City (NYC) properties. 10 | To make them available to users in both cases, specific metadata elements, e.g., latitude and longitude coordinates, are persisted in the Audit Template database at the building level, i.e., individual buildings may have their own latitude and longitude coordinates. 11 | Currently, it is not possible to represent this building level information as BuildingSync. 12 | 13 | ## Implementation 14 | 15 | This proposal is to: 16 | 17 | 1. Reify the following child elements of the `auc:SiteType` element and then add them to the `auc:BuildingType` element: 18 | * `auc:ClimateZoneType` 19 | * `auc:eGRIDRegionCode` 20 | * `auc:WeatherDataStationID` 21 | * `auc:WeatherStationName` 22 | * `auc:WeatherStationCategory` 23 | * `auc:Longitude` 24 | * `auc:Latitude` 25 | 26 | ## References 27 | 28 | n/a 29 | -------------------------------------------------------------------------------- /proposals/2019/Spatial Unit Occupied Percentage.md: -------------------------------------------------------------------------------- 1 | # MeasureScaleOfApplication - Add Enumerations 2 | 3 | ## Overview 4 | 5 | The percentage of dwellings occupied (or any spatial unit) is not defined. 6 | 7 | ## Justification 8 | 9 | Standard 211 requests the percentage of multifamily dwellings that are occupied. 10 | 11 | ## Implementation 12 | 13 | Since the spatial unit is a complex type, this will be a new element in the complex type. 14 | 15 | The new element name will be SpatialUnitOccupiedPercentage similar to the FloorAreaPercentage. 16 | 17 | ``` 18 | //element(*,auc:BuildingType)/auc:SpatialUnits/auc:SpatialUnit/auc:SpatialUnitOccupiedPercentage 19 | ``` 20 | 21 | ## References 22 | 23 | n/a 24 | -------------------------------------------------------------------------------- /proposals/2019/Terminal Unit Enumerations.md: -------------------------------------------------------------------------------- 1 | # Update TerminalUnit Enumerations 2 | 3 | ## Overview 4 | 5 | Add new terminal unit enumerations. The current list of enums on BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/HeatingAndCoolingSystems/Deliveries/Delivery/DeliveryType/CentralAirDistribution/TerminalUnit are: 6 | 7 | ```xml 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | ``` 19 | 20 | ## Justification 21 | 22 | For mapping between New York LL87 and Asset Score using BuildingSync there needs to exist a CAV terminal box without reheat and a powered induction terminal unit. 23 | 24 | ## Implementation 25 | 26 | Add the following enumerations: 27 | 28 | ```xml 29 | 30 | 31 | ``` 32 | 33 | ## References 34 | 35 | N/A 36 | 37 | -------------------------------------------------------------------------------- /proposals/2019/Ventilation.md: -------------------------------------------------------------------------------- 1 | # VentilationType and VentilationControlMethod 2 | 3 | ## Overview 4 | 5 | The MechanicalVentilation/VentilationType enumeration does not include None. There is also only a single type of ventilation control that is allowed. 6 | 7 | ## Justification 8 | 9 | The user can either leave out MechanicalVentilation or set MechanicalVentilation/VentilationType to None. 10 | 11 | The user should be able to select multiple ventilation control methods such as CO2 Sensors and Scheduled. 12 | 13 | ## Implementation 14 | 15 | * Add None to BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/OtherHVACSystems/OtherHVACSystem/OtherHVACType/MechanicalVentilation/VentilationType 16 | * Convert the following to a container with multiples allowed. *(This is a breaking change.)* 17 | * BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/OtherHVACSystems/OtherHVACSystem/OtherHVACType/MechanicalVentilation/VentilationControlMethods 18 | * BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/OtherHVACSystems/OtherHVACSystem/OtherHVACType/SpotExhaust/VentilationControlMethods 19 | * BuildingSync/Facilities/Facility/Systems/HVACSystems/HVACSystem/OtherHVACSystems/OtherHVACSystem/OtherHVACType/NaturalVentilation/VentilationControlMethods 20 | 21 | 22 | ## References 23 | 24 | N/A 25 | 26 | -------------------------------------------------------------------------------- /proposals/2019/gbXML_xrefs.md: -------------------------------------------------------------------------------- 1 | # BuildingSync Feature Proposal - External File Reference Support # 2 | 3 | ## Overview ## 4 | The following document is a feature proposal for supporting (multiple) external file references in BuildingSync, e.g. importing timeseries data from Green Button Data, and/or building geometry via gbXML, into BuildingSync. This FP will present the use case of a user wishing to import gbXML data into BuildingSync. 5 | 6 | ## Justification ## 7 | As a standardized language for exchanging commercial building data between audit tools, BuildingSync needs to also support building energy modeling tools and data exchange formats thereof (i.e., gbXML), as well as simulation-level data from either simulations or real building audits. BuildingSync must be capable of referencing and validating against multiple schemas simultaneously. 8 | 9 | ## Implementation ## 10 | ###Mapping gbXML-to-BldgSync 11 | 12 | | Building Sync | gbXML | 13 | | :---: | :---: | 14 | |Site | Campus | 15 | |Facility | Building | 16 | 17 | ###Schema Details 18 | 19 | * `Campus` (Building Sync `Site`) 20 | * `Building` (Buulding Sync `Facility`) 21 | * `BuildingStorey` 22 | * `PlanarGeometry` 23 | * `Space` (has a ZoneID) 24 | * `SpaceBoundary` - this field seems to define the bounding box(?) 25 | * Surface - `Surface` entries have `AdjacentSpaceId` (single), but no "SpaceId" or ZoneId". **Unclear how surface geometry is associated with spaces.** 26 | 27 | 28 | ###TODO 29 | 1. Add suppot for other gbXML elements (do we want to support non-geometry elements? e.g. Schedules) 30 | 2. Define mapping for low-level building elements 31 | 32 | ## References ## 33 | 34 | **gbXML** 35 | 36 | * [About gbXML](http://www.gbxml.org/About_GreenBuildingXML_gbXML) 37 | * [Sample gbXML files](https://github.com/GreenBuildingXML/Sample-gbXML-Files) 38 | * [Test Cases](http://www.gbxml.org/TestCases_for_GreenBuildingXML_gbXML) 39 | 40 | **Green Button** 41 | 42 | * [Green Button Data Developers](http://www.greenbuttondata.org/developers.html) 43 | * [Green Button Developers Repo](https://green-button.github.io/build/) 44 | * [Green Button Schema (XML)](https://github.com/energyos/OpenESPI-Common-java/blob/master/etc/espiDerived.xsd) 45 | * [Green Button Data Parser (Ruby)](https://github.com/cew821/greenbutton) 46 | 47 | **JSON** 48 | 49 | * [JSON Schema](https://cswr.github.io/JsonSchema/) 50 | * [JSON - auxiliary schema](https://cswr.github.io/JsonSchema/spec/definitions_references/) 51 | * [JSON Schema - combining schemas](https://json-schema.org/understanding-json-schema/reference/combining.html) 52 | * [allOf: usage](https://stackoverflow.com/questions/29781040/json-schema-possible-to-reference-multiple-schemas-from-one-object) 53 | 54 | -------------------------------------------------------------------------------- /proposals/2020/Add Annual Fuel Cost.md: -------------------------------------------------------------------------------- 1 | # Add AnnualFuelCost element 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `auc:AnnualFuelCost` child element to the `auc:ResourceUse` element. 6 | 7 | ## Justification 8 | 9 | Standard 211 sections 6.1.2.1.g and 6.1.2.1.i specifies 10 | > ... Annual electric use (kWh) and cost (\$) for each year 11 | > ... Annual site fuel (or other energy source) use in therms, 12 | gallons, lbs, MJ, or Btu, as appropriate, and cost (\$)... 13 | 14 | This proposal suggests that having an element `auc:AnnualFuelCost` in `auc:ResourceUse` would best address these requirements. 15 | 16 | ## Implementation 17 | 18 | ```xml 19 | 20 | 21 | ... 22 | 23 | 24 | Annual cost of the resource ($) 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | ... 35 | 36 | ``` 37 | 38 | ## References 39 | 40 | Standard 211 6.1.2.1.g and 6.1.2.1.i 41 | -------------------------------------------------------------------------------- /proposals/2020/Add Associated Cost to TimeSeries.md: -------------------------------------------------------------------------------- 1 | # Add Associated Cost to TimeSeries 2 | 3 | ## Overview 4 | 5 | This proposal is to include a method for associating cost ($) with time series data. 6 | 7 | ## Justification 8 | 9 | The monthly resource use cost is required information per Standard 211 6.1.2.1 (i), which states 10 | > Monthly utility data, including the following, for a minimum of 12 consecutive months (although three consecutive years is preferable), aggregated for the whole building by energy supplier, shall be reported using the forms in Normative Annex C (“Metered Energy” tab) ... **Annual site fuel (or other energy source) use in therms, gallons, lbs, MJ, or Btu, as appropriate, and cost ($); if fuel is delivered as a liquid or solid, a report of the annual amount used from actual delivered quantities or inventory change for each year** 11 | 12 | An important note is that STD 211 requires Total, Peak, and Cost for each Monthly metering interval. 13 | 14 | ## Implementation 15 | 16 | There are multiple options for implementation. 17 | 18 | ### Option 1 19 | Define a new enum for `auc:ReadingType`, `Cost`, in `auc:TimeSeries`. 20 | ```xml 21 | 22 | 23 | 24 | Total 25 | 2019-01-01T00:00:00 26 | 2019-02-01T00:00:00 27 | Month 28 | 123 29 | 30 | 31 | 32 | Peak 33 | 2019-01-01T00:00:00 34 | 2019-02-01T00:00:00 35 | Month 36 | 123 37 | 38 | 39 | 40 | 41 | Cost 42 | 2019-01-01T00:00:00 43 | 2019-02-01T00:00:00 44 | Month 45 | 1000 46 | 47 | 48 | 49 | 50 | ``` 51 | #### Pros 52 | - non-breaking change 53 | #### Cons 54 | - linking a cost to another reading (eg Total use) is non-trivial and must be done using Start and End Timestamps as well as the ResourceUseID's IDref. Specifically, one must: 55 | 1. Find all auc:ReadingType=Cost associated with a ResourceUse 56 | 1. Ensure start and end timestamps align across different auc:TimeSeries elements (i.e. the cost and the reading are referring to the same period of time). 57 | 58 | ### Option 2 59 | Change `auc:TimeSeries` to include `auc:IntervalReadings` which could contain multiple reading types. 60 | ```xml 61 | 62 | 63 | 64 | 65 | 66 | 123 67 | 123 68 | 1000 69 | 70 | 2019-01-01T00:00:00 71 | 2019-02-01T00:00:00 72 | Month 73 | 74 | 75 | 76 | 77 | ``` 78 | #### Pros 79 | - More concise modeling of meter data required by STD 211 80 | - easy to find associated cost with a reading, and can handle cost that's associated with multiple reading types 81 | #### Cons 82 | - breaking change 83 | - another layer of nesting, which is unnecessary if most people just use it for reporting only one reading type 84 | 85 | ## Decision 86 | We will implement Option 1 for now since it is non-breaking, and will move to Option 2 at a later time. 87 | -------------------------------------------------------------------------------- /proposals/2020/Add Canadian Provinces to States.md: -------------------------------------------------------------------------------- 1 | # Add Canadian Provinces to States 2 | 3 | ## Overview 4 | Add Canadian province abbreviations to acceptable `auc:State` enumeration restrictions. 5 | 6 | ## Justification 7 | 8 | To enable Canadian province and territory serialization. There are no conflicts with current enums. 9 | 10 | ## Implementation 11 | 12 | ```xml 13 | 14 | 15 | ... 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | ``` 33 | 34 | ## References 35 | https://en.wikipedia.org/wiki/ISO_3166-2:CA -------------------------------------------------------------------------------- /proposals/2020/Add Conveyance System Condition.md: -------------------------------------------------------------------------------- 1 | # Add Conveyance System Condition 2 | 3 | ## Overview 4 | 5 | This proposal is to add `auc:ConveyanceSystemCondition` to `auc:ConveyanceSystem`. 6 | 7 | ## Justification 8 | 9 | SPC 211 Standard for Commercial Building Energy Audits section 6.2.1.6.c states 10 | > Conveyance equipment (elevators, escalators, and automated people movers) shall be identified, including their condition (excellent, good, average, poor). 11 | 12 | ## Implementation 13 | 14 | Add an optional element `auc:ConveyanceSystemCondition` of type `auc:EquipmentCondition` to `auc:ConveyanceSystem`. 15 | -------------------------------------------------------------------------------- /proposals/2020/Add DHW Condition and Notes.md: -------------------------------------------------------------------------------- 1 | # Add DHW Condition and Notes 2 | 3 | ## Overview 4 | 5 | This proposal is to add `auc:DomesticHotWaterSystemCondition` and `auc:DomesticHotWaterSystemNotes` elements to `auc:DomesticHotWaterSystem`. 6 | 7 | ## Justification 8 | 9 | SPC 211 Standard for Commercial Building Energy Audits section 6.2.1.4.c specifies the following regarding Service/Domestic Hot Water 10 | > Assessment of general condition (excellent, good, average, poor). Determined by observation or testing and referring both to condition of equipment and energy use level, including notation of deficiencies. The report shall describe the methods of evaluation used and the basis for establishing system efficiency. 11 | 12 | Since there is no condition element for DHW in BuildingSync, nor an element for freeform notes, these two elements are necessary. 13 | 14 | ## Implementation 15 | 16 | Following BuildingSync convention of systems/entities with `auc:*Condition` and `auc:*Notes`, we will add the optional elements `auc:DomesticHotWaterSystemCondition` and `auc:DomesticHotWaterSystemNotes` as children to `auc:DomesticHotWaterSystem`. 17 | -------------------------------------------------------------------------------- /proposals/2020/Add Delivery Condition.md: -------------------------------------------------------------------------------- 1 | # Add Delivery Condition 2 | 3 | ## Overview 4 | 5 | This proposal is to add `auc:DeliveryCondition` element to `auc:Delivery` 6 | 7 | ## Justification 8 | 9 | Addressing HVAC system requirements, SPC 211 Standard for Commercial Building Energy Audits section 6.2.1.3.a states the report must include 10 | > Assessment of general condition (excellent, good, average, poor) determined by observation or testing, including notation of deficiencies 11 | 12 | This is already included for most subsystems of HVAC, `auc:CoolingSource`, `auc:HeatingSource`, `auc:CoolingPlant`, etc. but not included for `auc:Delivery`. 13 | 14 | ## Implementation 15 | 16 | Add optional element `auc:DeliveryCondition` to `auc:Delivery`. -------------------------------------------------------------------------------- /proposals/2020/Add Energy Cost Index.md: -------------------------------------------------------------------------------- 1 | # Add BenchmarkValue element 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `auc:EnergyCostIndex` child element to the `auc:AllResourceTotalType` element. 6 | 7 | ## Justification 8 | 9 | The `auc:EnergyCostIndex` element is specified as a required calculation per Standard 211 5.2.3.2. The `auc:EnergyCost` element already exists. This mimics the `auc:SiteEnergyUse` and `auc:SiteEnergyUseIntensity` pair of elements. 10 | 11 | ## Implementation 12 | 13 | ```xml 14 | 15 | 16 | The Energy Cost divided by the premises gross floor area. ($/ft2) 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | ``` 27 | 28 | ## References 29 | 30 | Standard 211 5.2.3.2 31 | -------------------------------------------------------------------------------- /proposals/2020/Add Energy Use Elements.md: -------------------------------------------------------------------------------- 1 | # Add Energy Use Elements 2 | 3 | ## Overview 4 | 5 | This proposal is to add the following children to `auc:AllResourceTotal` 6 | - `auc:BuildingEnergyUse` 7 | - `auc:BuildingEnergyUseIntensity` 8 | - `auc:ImportedEnergyConsistentUnits` 9 | - `auc:OnsiteEnergyProductionConsistentUnits` 10 | - `auc:ExportedEnergyConsistentUnits` 11 | - `auc:NetIncreaseInStoredEnergyConsistentUnits` 12 | 13 | ## Justification 14 | 15 | Standard 211 refers to ASHRAE 105 for defining specific terms related to energy use. Within ASHRAE 105, there is a clear distinction between Building Energy and Site Energy, as depicted by ASHRAE 105 Figure 5.6. Additionally defined in ASHRAE 105 are the following intermediate calculation concepts: 16 | 17 | - Imported Energy 18 | - Exported Energy 19 | - On-Site Renewable Energy Production 20 | - Net Increase in Stored Imported Energy 21 | 22 | Currently, the auc:AllResourceTotal complex type includes: 23 | 24 | - auc:SiteEnergyUse 25 | - auc:SiteEnergyUseIntensity 26 | 27 | We want to shore up this representation by distinctly aligning BuildingSync elements with ASHRAE 105, with the intention of making the distinction between Building and Site energy more clear, as well as having a referenceable standard by which users can refer for making energy calculations for their site or building. This would better align calculations to the 211 spreadsheet as well. 28 | 29 | ## Implementation 30 | 31 | The structure for each element would be the same 32 | ```xml 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | ``` 42 | 43 | ## References 44 | 45 | Standard 211 sections 5.2.3 and 5.2.3.1 46 | -------------------------------------------------------------------------------- /proposals/2020/Add Engineering Calculation.md: -------------------------------------------------------------------------------- 1 | # Add EngineeringCalculation element 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `auc:EngineeringCalculation` element as a calculation method. 6 | 7 | ## Justification 8 | 9 | The `auc:CalculationMethodType` element is used as a child element of the `auc:ScenarioType` to help further refine how information in the scenario was derived. This might include energy consumption information, costs, savings, etc. 10 | 11 | The current sequence of items that can be used to define an `auc:CalculationMethodType` are as follows: 12 | - `auc:Modeled` - used to represent when a whole building energy modeling application is used. 13 | - `auc:Measured` - used to represent when actual measurements (utility, AMI, HOBO devices, etc.) are used to capture real data from the building 14 | - `auc:Estimated` - used to represent a 'guess' or 'judgment call' 15 | - `auc:Other` - anything else 16 | 17 | There is currently no good way to represent information that, although may not be modeled in a BEM application, was derived with some knowledge of the building and a spreadsheet, for example. The following complex type is introduced as a placeholder to represent that situation. There currently is no way to specify __how__ the calculation was made - pending the use of this element, this may be added in the future. 18 | 19 | ## Implementation 20 | 21 | ```xml 22 | 23 | 24 | 25 | ... 26 | 27 | 28 | ... 29 | 30 | 31 | 32 | 33 | 34 | 35 | ... 36 | 37 | 38 | ``` 39 | -------------------------------------------------------------------------------- /proposals/2020/Add Infiltration Notes.md: -------------------------------------------------------------------------------- 1 | # Add Infiltration Notes 2 | 3 | ## Overview 4 | 5 | This proposal is to add `auc:AirInfiltrationNotes` and `auc:WaterInfiltrationNotes` elements to meet SPC 211 Standard for Commercial Building Energy Audits requirements. 6 | 7 | ## Justification 8 | 9 | SPC 211 Standard for Commercial Building Energy Audits section 6.2.1.2.e states 10 | > Results of assessment of the enclosure’s overall tightness against air infiltration/exfiltration, coordinated with the assessment of building ventilation per Section 5.4.5.2(n), including a statement of the auditor’s methods used, criteria, evidence, and basis of evaluation (Assessment shall include an overall condition rating on a scale of 1 [poor = high infiltration/exfiltration] to 3 [excellent = tight, low infiltration/exfiltration].) 11 | 12 | Currently there's no way for users to specify methods/criteria/evidence etc of the infiltration assessment. This new element addresses this need. 13 | 14 | ## Implementation 15 | 16 | Add optional elements `auc:AirInfiltrationNotes` and `auc:WaterInfiltrationNotes` to `auc:AirInfiltrationSystem` and `auc:WaterInfiltrationSystem`, respectively. 17 | -------------------------------------------------------------------------------- /proposals/2020/Add Interval Duration.md: -------------------------------------------------------------------------------- 1 | # Add Interval Duration 2 | 3 | ## Overview 4 | 5 | This proposal is to add `auc:IntervalDuration` and `auc:IntervalDurationUnits` elements in order to better validate and specify time series durations. 6 | 7 | ## Justification 8 | 9 | SPC 211 Standard for Commercial Building Energy Audits section 6.2.2.1.a.6 requires "Number of days in month or period" for Historical Utility Data. 10 | 11 | ## Implementation 12 | 13 | Add `auc:IntervalDuration` and `auc:IntervalDurationUnits` to `auc:TimeSeries`. Interval duration will be an integer, and duration units will have the same enums as `auc:IntervalFrequency` -------------------------------------------------------------------------------- /proposals/2020/Add Lighting Automation System.md: -------------------------------------------------------------------------------- 1 | # Add Lighting Automation System 2 | 3 | ## Overview 4 | 5 | This proposal is to add `auc:LightingAutomationSystem` element at the `auc:Building` and `auc:LightingSystem` levels. 6 | 7 | ## Justification 8 | 9 | In reference to lighting systems, SPC 211 Standard for Commercial Building Energy Audits requires 10 | > A listing of lighting control system types (manual switching, step switching, dimmers, photosensors, occupancy sensors, timers) 11 | 12 | BuildingSync is capable of handling the controls mentioned, however there's no notion of lighting automation systems in the schema, which is relevant to lighting controls. 13 | 14 | ## Implementation 15 | 16 | Add an optional, boolean element `auc:LightingAutomationSystem` at the `auc:Building` and `auc:LightingSystem`. 17 | -------------------------------------------------------------------------------- /proposals/2020/Add Load Factor to Reading Type.md: -------------------------------------------------------------------------------- 1 | # Add Load Factor to Reading Type 2 | 3 | ## Overview 4 | 5 | This proposal is to add `Load factor` enum to `auc:ReadingType` 6 | 7 | ## Justification 8 | 9 | SPC 211 Standard for Commercial Building Energy Audits section 6.2.2.1.a.10 requires "Monthly or period load factor (%)." for Historical Monthly Utility Readings. 10 | 11 | ## Implementation 12 | 13 | Add a new `auc:ReadingType` enum, "Load factor" 14 | -------------------------------------------------------------------------------- /proposals/2020/Add Nonquantifiable Factors.md: -------------------------------------------------------------------------------- 1 | # Update Annual Fuel Use Native Units 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `auc:NonquantifiableFactors` element to `auc:PackageOfMeasures`. 6 | 7 | ## Justification 8 | 9 | SPC 211 Standard for Commercial Building Energy Audits section 6.2.6.1 states 10 | >For each practical measure, report ... Include a description of the nonquantifiable factors... 11 | 12 | Nonquantifiable factors should really be interpreted as 'factors that are highly difficult to quantify, or unquantifiable given the existing infrastructure or budget'. This might include aspects such as: 13 | 14 | - Improve indoor air quality 15 | - Improve occupant comfort 16 | - Improve occupant satisfaction 17 | - Reduce glare 18 | - Improve access to daylight 19 | etc. 20 | 21 | ## Implementation 22 | 23 | Add `auc:NonquantifiableFactors` to `auc:PackageOfMeasures` as a free-form text field. 24 | -------------------------------------------------------------------------------- /proposals/2020/Add Number of Sides to Section.md: -------------------------------------------------------------------------------- 1 | # Update Annual Fuel Use Native Units 2 | 3 | ## Overview 4 | 5 | This proposal is to add `auc:NumberOfSides` element to `auc:Section` to allow validation for number of sides provided in `auc:Sides` when `auc:FootprintShape` is Other. 6 | 7 | ## Justification 8 | 9 | If a document has `auc:FootprintShape` of Other, we cannot validate the number of provided `auc:Side`s, which we plan on doing for the 211 Level 2 use case. Adding this element will allow us to validate the number of sides. 10 | 11 | ## Implementation 12 | 13 | Add an optional simple type element `auc:NumberOfSides` in `auc:Section` which accepts a positive integer. 14 | -------------------------------------------------------------------------------- /proposals/2020/Add Peak Type.md: -------------------------------------------------------------------------------- 1 | # Add Peak Type 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `auc:PeakType` element in order to specify what type of peak a given reading is. 6 | 7 | ## Justification 8 | 9 | SPC 211 Standard for Commercial Building Energy Audits section 6.2.2.1.a.8 requires "Actual or billed (or both if reported) peak electric demand (kW), identified as on-peak, mid-peak, and off-peak" for Historical Monthly Utility Data. 10 | 11 | ## Implementation 12 | 13 | Inside of auc:TimeSeries, create a new element `auc:PeakType` as a child element of the TimeSeriesType with options of on-peak, mid-peak, and off-peak. -------------------------------------------------------------------------------- /proposals/2020/Add Resource Use Notes.md: -------------------------------------------------------------------------------- 1 | # Add ResourceUseNotes element 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `auc:ResourceUseNotes` child element to the `auc:ResourceUse` element. 6 | 7 | ## Justification 8 | 9 | Standard 211 sections 6.1.2.1.d and 6.1.2.1.j specify 10 | > ... If meter sampling is used by the qualified energy auditor, [the report must include] the sampling methodology used for each fuel 11 | > ... Identification of irregularities in monthly energy use patterns and suggestions about their possible causes 12 | 13 | This proposal suggests that having an element freeform text notes within `auc:ResourceUse` would best address these requirements. 14 | 15 | ## Implementation 16 | 17 | ```xml 18 | 19 | 20 | ... 21 | 22 | 23 | Notes about the resource use; for example, meter sampling methodology 24 | 25 | 26 | 27 | ``` 28 | 29 | This is similar to the approach taken for freeform text necessary to be defined at the `auc:Building` level, where the `auc:PremisesNotes` field is used to capture freeform text. 30 | 31 | ## References 32 | 33 | Standard 211 6.1.2.1.d and 6.1.2.1.j 34 | -------------------------------------------------------------------------------- /proposals/2020/Add Simple Impact Analysis.md: -------------------------------------------------------------------------------- 1 | # Add Simple Impact Analysis 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `auc:SimpleImpactAnalysis` and `auc:CostCategory` child elements to the `auc:PackageOfMeasures` element. 6 | 7 | ## Justification 8 | 9 | Standard 211 6.1.5.c-6.1.5.g as well as 6.1.6.d-6.1.6.g requires a summary of the impact of each recommended measure. Specifically, it states: 10 | > c. Impact on occupant comfort (improved thermal comfort, indoor air quality [IAQ], lighting quality, acoustics) 11 | > d. Estimated cost (high, medium, low) 12 | > e. Estimated level (high, medium, low) of annual savings 13 | > f. Estimated level (high, medium, low) of return on investment (ROI) 14 | > g. Priority (high, medium, low) 15 | 16 | Additionally, Standard 211 is explicit in discriminating the "Low-Cost and No-Cost" recommendations (section 6.1.5) from the "Capital" recommendations (section 6.1.6), so it might not be a bad idea to add a category to specify this. 17 | 18 | ## Implementation 19 | 20 | In `auc:SimpleImpactAnalysis` add these elements which can have the values of `Low` `Medium` or `High` 21 | - EstimatedCost 22 | - EstimatedAnnualSavings 23 | - EstimatedROI 24 | - Priority 25 | 26 | Note that we tried to determine what _type_ of savings `EstimatedAnnualSavings` should represent (cost or energy) however neither STD 211 nor the normative spreadsheet specify this information, which is why we decided to just use the same wording. 27 | 28 | Also add `CostCategory` to `PackageOfMeasures` to specify if it's a low/no-cost or capital package. 29 | 30 | Also add `ImpactOnOccupantComfort`, but it should be a freeform text field b/c per 211 it captures and describes multiple things. 31 | 32 | ```xml 33 | 34 | 35 | 36 | ... 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | ... 53 | 54 | 55 | 56 | ... 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | ``` 65 | 66 | ## References 67 | 68 | Standard 211 6.1.5.c-6.1.5.g 69 | -------------------------------------------------------------------------------- /proposals/2020/Add install electrical storage measure.md: -------------------------------------------------------------------------------- 1 | # Add Install Electrical Storage 2 | 3 | ## Overview 4 | 5 | FEMP's Compiance Tracking System (CTS) has "Install electrical storage" as a measure. 6 | 7 | ## Justification 8 | 9 | One of the goals of BuildingSync is to stay aligned with CTS. 10 | 11 | ## Implementation 12 | 13 | Add a `Install electrical storage` as an enumeration of `MeasureName` under `RenewableEnergySystems`. 14 | -------------------------------------------------------------------------------- /proposals/2020/Allow Multiple Door IDs for Side.md: -------------------------------------------------------------------------------- 1 | # Allow Multiple Doors for Side 2 | 3 | ## Overview 4 | 5 | This proposal is to modify the `auc:Side` to allow an unbounded number of `auc:DoorID`s to be referenced 6 | 7 | ## Justification 8 | 9 | Currently you can only reference one door ID for each `auc:Side`. This is an issue if a side of a building has multiple door types. 10 | 11 | ## Implementation 12 | 13 | This proposal suggests the schema creates a choice between a single `auc:DoorID` (how things currently are), or `auc:DoorIDs` which contains an unbounded number of door IDs. This is non-breaking and the former choice could be dropped in the next major release. 14 | -------------------------------------------------------------------------------- /proposals/2020/Allow Multiple Walls for Side.md: -------------------------------------------------------------------------------- 1 | # Allow Multiple Walls for Side 2 | 3 | ## Overview 4 | 5 | This proposal is to modify the `auc:Side` to allow an unbounded number of `auc:Wall` IDs to be referenced 6 | 7 | ## Justification 8 | 9 | Currently you can only reference one wall ID for each `auc:Side`. This is an issue if a side of a building is composed of more than one wall type. 10 | 11 | ## Implementation 12 | 13 | This proposal suggests the schema creates a choice between a single `auc:WallID` (how things currently are), or `auc:WallIDs` which contains an unbounded number of wall IDs. This is non-breaking and the former choice could be dropped in the next major release. 14 | -------------------------------------------------------------------------------- /proposals/2020/Allow Multiple Windows for Side.md: -------------------------------------------------------------------------------- 1 | # Allow Multiple Windows for Side 2 | 3 | ## Overview 4 | 5 | This proposal is to modify the `auc:Side` to allow an unbounded number of `auc:WindowID`s to be referenced 6 | 7 | ## Justification 8 | 9 | Currently you can only reference one window ID for each `auc:Side`. This is an issue if a side of a building has multiple window types. 10 | 11 | ## Implementation 12 | 13 | This proposal suggests the schema creates a choice between a single `auc:WindowID` (how things currently are), or `auc:WindowIDs` which contains an unbounded number of window IDs. This is non-breaking and the former choice could be dropped in the next major release. 14 | -------------------------------------------------------------------------------- /proposals/2020/BuildingSync Versioning.md: -------------------------------------------------------------------------------- 1 | # BuildingSync Versioning 2 | 3 | ## Overview 4 | 5 | This proposal is to formalize BuildingSync's approach to versioning and releases. 6 | 7 | ## Justification 8 | 9 | Having consistent meanings of versions is helpful to users. By the version alone, a user could determine whether or not an implementation of BuildingSync supports their existing documents or not. 10 | 11 | ## Implementation 12 | 13 | The versioning of BuildingSync schema should follow [semantic versioning](https://semver.org/). Since semantic versioning (semver) is more directed towards APIs, it can be helpful to translate the meaning of breaking changes, non-breaking features, and patches. When thinking about the API of an xml schema, consider XPaths, when and how they break, as well as document validation, when and how historical documents are no longer valid, as these are the use cases of XML documents. 14 | 15 | ### Breaking changes 16 | These are the changes that require a new MAJOR version. Generally this would be any time where there _could_ exist a historical document that would not validate against the new schema. This would include: 17 | - adding a required element/attribute that was not previously required 18 | - moving the location of an existing element or changing its name (e.g. moving order in sequence or to different parent) 19 | - changing to an incompatible type (e.g. decimal to integer) 20 | - changing the restrictions for a simple type to something which is not the superset of the previous restriction 21 | 22 | ### Non-breaking features 23 | These are the changes that require a new MINOR version. This would include any changes which are meaningful changes to the schema, but do not break the validation of historical documents. For example: 24 | - adding a new non-required element/attribute 25 | - changing a simple type to a compatible type (e.g. decimal to string) 26 | - adding a new enum option for a simple type 27 | 28 | ### Patches 29 | These are the changes that require a new PATCH version. This would include changes which do not meaningfully change the schema. For example: 30 | - updating the documentation 31 | - restructuring the XSD without changing the schema (e.g. turning an inline element definition into a reference or creating a new type) 32 | 33 | 34 | ### Version management 35 | I propose BuildingSync supports the two most recent MAJOR versions at a time. Support for a version means it will receive all new non-breaking changes (ie MINOR and PATCH changes). 36 | 37 | BuildingSync should maintain two branches for each MAJOR version, develop and main. For example, for versions 2 and 3, you could have `develop-v2`, `main-v2`, `develop-v3` and `main-v3`. All releases (ie tags) are made off of the `main` branches. When ready for a new release, the maintainer merges the develop branch into main, then tags the last commit. 38 | 39 | To add a non-breaking change to the currently supported versions, the developer applies it to one of the develop branches then cherry picks or manually transfers the changes to the other develop branch. 40 | -------------------------------------------------------------------------------- /proposals/2020/Change Primary to Principal HVAC.md: -------------------------------------------------------------------------------- 1 | # Change Primary HVAC to Principal HVAC 2 | 3 | ## Overview 4 | 5 | This proposal is to change the element `auc:PrimaryHVACSystemType` element to the `auc:PrincipalHVACSystemType` element. 6 | 7 | ## Justification 8 | 9 | In Standard 211, the term "Principal HVAC" is used rather than "Primary HVAC", see section 5.3.4. 10 | 11 | ## Implementation 12 | Change the element name to `auc:PrincipalHVACSystemType`, and update annotation documentation to say principal. 13 | 14 | 15 | ## Decision 16 | We will allow users to use _either_ `auc:PrimaryHVACSystemType` or `auc:PrincipalHVACSystemType` for now, and add a warning that `PrimaryHVACSystemType` is being deprecated. It should be fully removed in the next major version. 17 | 18 | ## References 19 | 20 | Standard 211 5.3.4 21 | -------------------------------------------------------------------------------- /proposals/2020/Deprecate ReadingType Cost.md: -------------------------------------------------------------------------------- 1 | # Deprecate ReadingType Cost 2 | 3 | ## Overview 4 | 5 | This proposal is to deprecate the enum "Cost" within `auc:ReadingType` of `auc:TimeSeries`. 6 | 7 | ## Justification 8 | 9 | `auc:ReadingType` should describe how a value was calculated, not its "units" or the quantity being measured. In addition `TimeSeriesReadingQuantity` already has Currency. 10 | 11 | This proposal suggests that we deprecate Cost, and change `TimeSeriesReadingQuantity`'s Currency to Cost. 12 | -------------------------------------------------------------------------------- /proposals/2020/Resource Use Submetering.md: -------------------------------------------------------------------------------- 1 | # Resource Use Submetering 2 | 3 | ## Overview 4 | 5 | This proposal is to modify `auc:ResourceUse` to allow modeling of submeters. 6 | 7 | ## Justification 8 | 9 | SPC 211 Standard for Commercial Building Energy Audits section 6.2.2.1.d states the following regarding historical utility data. 10 | > A description of the submetering installed in the building (if present), including a listing of the systems metered, the frequency of data recording, and a description of the data acquisition system (fixed, portable, or integrated with the BAS), shall be provided. 11 | 12 | ## Implementation 13 | 14 | ### Option 1 15 | Use ResourceUses to model submetering by adding the elements `auc:MeterID` and `auc:ParentResourceUseID`. `auc:MeterID` should contain the ID of the meter as seen by the facility manager. `auc:ParentResourceUseID` links to another `auc:ResourceUse` to signify that it's a submeter of the parent resource use. 16 | 17 | #### Pros 18 | - simple, no breaking changes 19 | 20 | #### Cons 21 | - Not great data modeling 22 | 23 | ### Option 2 24 | Implement a new metering modeling system. This would incur a breaking change most likely, and the implementation is currently uncertain. 25 | 26 | #### Pros 27 | - better data modeling 28 | 29 | #### Cons 30 | - breaking change 31 | 32 | ## Decision 33 | 34 | We've decided to go with Option 1 for now, and push the refactoring of meter modeling to BuildingSync v3 35 | -------------------------------------------------------------------------------- /proposals/2020/Update Annual Fuel Use Native Units.md: -------------------------------------------------------------------------------- 1 | # Update Annual Fuel Use Native Units 2 | 3 | ## Overview 4 | 5 | This proposal is to modify the `auc:AnnualFuelUseNativeUnits` element in order to more clearly specify how it's value was calculated. 6 | 7 | ## Justification 8 | 9 | In the 211 Spreadsheet, annual fuel use is calculated using the "Main Data For Analysis - " table (All - Metered Energy tab) for each resource. The calculation is `annual fuel use = (total resource use) / (total number of days in monthly meter report) * 365`. For BuildingSync, the calculation of this value, annual fuel use, can be ambiguous: which `auc:TimeSeries` were included in the calculation? This is an issue because the standard allows more than just 12 consecutive months, and we don't have a way to specify which data were included in the calculation. 10 | 11 | ## Implementation 12 | 13 | ### Option 1 14 | Update documentation specifying that, for 211 reports, `auc:AnnualFuelUseNativeUnits` should only include the 12 most recent monthly meter readings. This isn't too different from the existing documentation. 15 | #### Pros 16 | - simple, no changes to schema 17 | 18 | #### Cons 19 | - validation can be a bit tricky (verifying the calculation was done correctly), e.g. what if they report the data in weekly intervals? 20 | 21 | ### Option 2 22 | Add new attributes to `auc:AnnualFuelUseNativeUnits`, `auc:StartDate` and `auc:EndDate`, which indicate the time frame used to calculate the annual 23 | 24 | ```xml 25 | 26 | 27 | Sum of all time series values for the past year, in the original units. (units/yr) 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | ``` 41 | 42 | #### Pros 43 | - explicit, calculations easily replicable. 44 | 45 | #### Cons 46 | - more complexity 47 | 48 | ## Option 3 49 | 50 | Add `AnnualFuelUseIncludedTimeSeries` to `auc:ResourceUse`, which contains a list of linked `auc:TimeSeries` IDs. 51 | 52 | ```xml 53 | 54 | 55 | Links to all time series data used to calculate the AnnualFuelUse values. 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | ``` 68 | 69 | ## Decision 70 | 71 | Option 1 is not compatible with the way Audit Template Tool calculates AnnualFuelUse, so we ruled it out. Option 2 is less desirable because it's valid to define even when TimeSeries data isn't included in the document, which isn't ideal. 72 | 73 | We are moving forward with Option 3 because it follows the general pattern of linking in BuildingSync and is very explicit. 74 | -------------------------------------------------------------------------------- /proposals/2020/img/DerivedModelIO.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/proposals/2020/img/DerivedModelIO.png -------------------------------------------------------------------------------- /proposals/2020/img/DerivedModelType.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/proposals/2020/img/DerivedModelType.png -------------------------------------------------------------------------------- /proposals/2021/Add AuditFilingStatus.md: -------------------------------------------------------------------------------- 1 | # Add AuditFilingStatus 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `AuditFilingStatus` element as a child of `ReportType` element, and to restrict the options with `Initial filing` and `Amended filing`. 6 | 7 | ## Justification 8 | 9 | This field originally took place in the audit reports for the city of Atlanta, but we believe it is a good field and therefore propose to add it to the schema. 10 | 11 | ## UDFs 12 | 13 | Currently this is conveyed via: 14 | `/auc:BuildingSync/auc:Facilities/auc:Facility/auc:Reports/auc:Report[auc:LinkedPremisesOrSystem/auc:Building/auc:LinkedBuildingID]/auc:UserDefinedFields/auc:UserDefinedField[auc:FieldName/text() = Audit Filing Status]/auc:FieldValue` in the Audit Template Field Group ATL. Our proposal is to add it as a child element of `ReportType` and provide enumerated options (starting with `Initial filing` and `Amended filing`). 15 | 16 | ## Example 17 | 18 | ```xml 19 | ... 20 | 21 | 22 | 23 | 24 | Initial Filing 25 | 26 | 27 | 28 | 29 | ... 30 | ``` 31 | 32 | ## Implementations 33 | 34 | ```xml 35 | 36 | 37 | ... 38 | 39 | 40 | The status of an audit filing, used to clarify whether or not this audit report is an initial submission (Initial filing) or an amendment to a previously submitted report (Amended filing). 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | ... 50 | ``` 51 | 52 | ## References -------------------------------------------------------------------------------- /proposals/2021/Add AuditorYearsOfExperience.md: -------------------------------------------------------------------------------- 1 | # Add AuditorYearsOfExperience 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `AuditorYearsOfExperience` child element to the `Qualification` element. This mirrors where other qualification data for an auditor is currently housed. 6 | 7 | ## Justification 8 | 9 | Certain AHJs require a minimum number of years experience for an auditor. This element would address the need to add that to the schema. 10 | 11 | ### UDFs 12 | Currently, this is conveyed in Audit template via: `/auc:BuildingSync/auc:Facilities/auc:Facility/auc:Reports/auc:Report[auc:LinkedPremisesOrSystem/auc:Building/auc:LinkedBuildingID]/auc:UserDefinedFields/auc:UserDefinedField[auc:FieldName/text() = Auditor Years Of Experience]/auc:FieldValue`. Our proposal is that it would rather look like: 13 | 14 | ```xml 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | Professional Engineer (PE) 23 | 4 <--> 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | Energy Auditor 33 | 34 | 35 | 36 | 37 | 38 | 39 | ``` 40 | 41 | ## Implementation 42 | 43 | ```xml 44 | 45 | 46 | 47 | Qualifications of audit team. 48 | 49 | 50 | 51 | ... 52 | 53 | 54 | The number of years the energy auditor has been conducting audits professionally. 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | ... 65 | 66 | 67 | ``` 68 | 69 | ## References 70 | 71 | -------------------------------------------------------------------------------- /proposals/2021/Add AverageAnnualOperatingHours.md: -------------------------------------------------------------------------------- 1 | # Add AverageAnnualOperatingHours to System 2 | 3 | ## Overview 4 | This proposal is to add the `AverageAnnualOperatingHours` element as a child element of `OnsiteStorageTransmissionGenerationSystem` under `System`. 5 | 6 | ## Justification 7 | The average operating hours per year of the onsite generation system. 8 | 9 | ## UDFs 10 | Currently this is conveyed in Audit Template via: `/auc:BuildingSync/auc:Facilities/auc:Facility/auc:Sites/auc:Site/auc:Buildings/auc:Building/auc:UserDefinedFields/auc:UserDefinedField[auc:FieldName/text() = Onsite Generation Operation Average Annual Hours]/auc:FieldValue`. Our proposal is to add it as a child element of `OnsiteStorageTransmissionGenerationSystem`. 11 | 12 | ## Example 13 | ```xml 14 | ... 15 | 16 | 17 | 18 | 19 | 20 | 21 | 4000 22 | 23 | 24 | 25 | 26 | 27 | 28 | ... 29 | ``` 30 | 31 | ## Implementation 32 | ```xml 33 | ... 34 | 35 | 36 | 37 | 38 | The average operating hours per year of the onsite generation system. 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | ... 48 | ``` 49 | 50 | ## References -------------------------------------------------------------------------------- /proposals/2021/Add EarlyCompliance.md: -------------------------------------------------------------------------------- 1 | # Add EarlyCompliance 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `EarlyCompliance` element as a child of `ReportType` element, with boolean options. 6 | 7 | ## Justification 8 | 9 | This field originally took place in the audit reports for the city of Atlanta, but we believe it is a good field and therefore propose to add it to the schema. It's true if the audit report was submitted before the compliance deadline. 10 | 11 | ## UDFs 12 | 13 | Currently this is conveyed via: 14 | `/auc:BuildingSync/auc:Facilities/auc:Facility/auc:Reports/auc:Report[auc:LinkedPremisesOrSystem/auc:Building/auc:LinkedBuildingID]/auc:UserDefinedFields/auc:UserDefinedField[auc:FieldName/text() = Early Compliance]/auc:FieldValue` in the Audit Template Field Group ATL. Our proposal is to add it as a child element of `ReportType` with boolean options. 15 | 16 | ## Example 17 | 18 | ```xml 19 | ... 20 | 21 | 22 | 23 | 24 | True 25 | 26 | 27 | 28 | 29 | ... 30 | ``` 31 | 32 | ## Implementations 33 | 34 | ```xml 35 | 36 | 37 | ... 38 | 39 | 40 | True if the audit report was submitted before the compliance deadline. 41 | 42 | 43 | ... 44 | ``` 45 | 46 | ## References -------------------------------------------------------------------------------- /proposals/2021/Add MaximumOutsideAirFlowRate.md: -------------------------------------------------------------------------------- 1 | # Add MaximumOutsideAirFlowRate 2 | 3 | ## Overview 4 | 5 | This proposal is to create the element `auc:MaximumOutsideAirFlowRate` as alternative choice to `auc:MaximumOAFlowRate`. 6 | 7 | ## Justification 8 | 9 | All other elements use `OutsideAir`. To keep consistent naming, we will substitute `auc:MaximumOAFlowRate` under `auc:DuctSystem` with `auc:MaximumOutsideAirFlowRate` (by adding it as a choice element to make it non-breaking change) and deprecate `auc:MaximumOAFlowRate` in version 3.0. 10 | 11 | ## Implementation 12 | 13 | As a non-breaking change for 2.4, we will move `auc:MaximumOAFlowRate` into a choice, and provide `auc:MaximumOutsideAirFlowRate` as the alternative. Annotate `auc:MaximumOAFlowRate` with a deprecation warning. 14 | As a breaking change for 3.0, we will replace `auc:MaximumOAFlowRate` with `auc:MaximumOutsideAirFlowRate`. 15 | 16 | ## References 17 | -------------------------------------------------------------------------------- /proposals/2021/Add MultiTenant.md: -------------------------------------------------------------------------------- 1 | # Add MultiTenant to Building 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `MultiTenant` element as a child element of `Building` element, with boolean options. 6 | 7 | ## Justification 8 | 9 | True if the building is a multi-tenant building. 10 | 11 | ## UDFs 12 | 13 | Currently this is conveyed in Audit Template via: 14 | `/auc:BuildingSync/auc:Facilities/auc:Facility/auc:Sites/auc:Site/auc:Buildings/auc:Building/auc:UserDefinedFields/auc:UserDefinedField[auc:FieldName/text() = Multi Tenant]/auc:FieldValue`. 15 | Our proposal is to add it under a `Building`. 16 | 17 | ## Example 18 | 19 | ```xml 20 | 21 | 22 | 23 | 24 | True 25 | 26 | 27 | 28 | 29 | ``` 30 | 31 | ## Implementation 32 | 33 | ```xml 34 | 35 | 36 | 37 | 38 | 39 | A building is a single structure wholly or partially enclosed within exterior walls, or within exterior and abutment walls (party walls), and a roof, affording shelter to persons, animals, or property. A building can be two or more units held in the condominium form of ownership that are governed by the same board of managers. 40 | 41 | 42 | 43 | 44 | 45 | ... 46 | 47 | 48 | True if the building is a multi-tenant building. 49 | 50 | 51 | ... 52 | ``` 53 | 54 | ## References -------------------------------------------------------------------------------- /proposals/2021/Add PRMS.md: -------------------------------------------------------------------------------- 1 | # Add PRMS in eGRIDRegionCode 2 | 3 | ## Overview 4 | 5 | This proposal is to add the enumeration `PRMS` under `eGRIDRegionCode` element. 6 | 7 | ## Justification 8 | 9 | In February 2021, a new eGRID subregion was added: "PRMS (Puerto Rico Miscellaneous)", which currently is not an enumeration of the `auc:eGRIDRegionCode` element. 10 | 11 | ## References 12 | Page 4 in [https://www.epa.gov/sites/default/files/2021-04/documents/emission-factors_apr2021.pdf](https://www.epa.gov/sites/default/files/2021-04/documents/emission-factors_apr2021.pdf) 13 | -------------------------------------------------------------------------------- /proposals/2021/Add TotalCommonConditionedAboveGradeWallArea.md: -------------------------------------------------------------------------------- 1 | # Add TotalCommonConditionedAboveGradeWallArea 2 | 3 | ## Overview 4 | 5 | This proposal is to add the `TotalCommonConditionedAboveGradeWallArea` child element under the `Building` element. This captures the total area of the above grade wall common with other conditioned buildings. 6 | 7 | ## Justification 8 | 9 | Audit Template Tool defines demising wall as the total area of the above grade wall common with other conditioned buildings, as an overall building characteristic. However, the term demising wall has conflicting definition in other standards (such as interior partitions). To avoid ambiguity, we adopt the descriptive name `TotalCommonConditionedAboveGradeWallArea` instead of `DemisingAboveGradeWallArea`. 10 | 11 | ### UDFs 12 | Currently, this is conveyed in Audit template via: `/auc:BuildingSync/auc:Facilities/auc:Facility/auc:Sites/auc:Site/auc:Buildings/auc:Building/auc:UserDefinedFields/auc:UserDefinedField[auc:FieldName/text() = Demising Above Grade Wall Area]/auc:FieldValue`. Our proposal is that it would rather look like: 13 | 14 | ```xml 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 1000 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | ``` 31 | 32 | ## Implementation 33 | 34 | ```xml 35 | 36 | 37 | 38 | 39 | 40 | 41 | A building is a single structure wholly or partially enclosed within exterior walls, or within exterior and abutment walls (party walls), and a roof, affording shelter to persons, animals, or property. A building can be two or more units held in the condominium form of ownership that are governed by the same board of managers. 42 | 43 | 44 | 45 | 46 | 47 | ... 48 | 49 | 50 | The total area of the above grade wall common with other conditioned buildings. (ft2) 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | ... 61 | ``` 62 | 63 | ## References 64 | https://help.buildingenergyscore.com/support/solutions/articles/8000053362-facility-description-construction (even though their usage of the term demising wall is incorrect) 65 | ASHRAE Standard 211 6.2.1.2.b 66 | -------------------------------------------------------------------------------- /proposals/2021/Add eGRIDSubregionCodes.md: -------------------------------------------------------------------------------- 1 | # Add eGRIDSubregionCodes 2 | 3 | ## Overview 4 | 5 | This proposal is to create the element `auc:eGRIDSubregionCodes`, which has one or more `auc:eGRIDSubregionCode` elements, to substitute the function of `auc:eGRIDRegionCode` and allow multiple eGRID Subregion Codes with the `auc:Site` and/or `auc:Building`. 6 | 7 | ## Justification 8 | 9 | Given an eGRID-assigned zip code, the power profiler zip code tool (see reference) returns between 1 and 3 eGRID subregion codes, referred to as "eGRID Subregion 1", "eGRID Subregion 2" and "eGRID Subregion 3", respectively. 10 | Currently, in BuildingSync XML schema, Only 1 eGRID subregion code can be asserted for a given `auc:Site` and `auc:Building` element. 11 | We decide that BuildingSync should handle multiple eGRID Subregion Codes. The main motivation for allowing multiple codes is that users should use the average of coefficients for multiple region codes. 12 | We are currently reaching out to determine if/how we should add these codes to `auc:Utility`. 13 | 14 | ## Implementation 15 | 16 | We will create an element `auc:eGRIDSubregionCodes`, which has one or more `auc:eGRIDSubregionCode` elements. 17 | As a non-breaking change for 2.4, we will move `auc:eGRIDRegionCode` into a choice, and provide `auc:eGRIDSubregionCodes` as the other option. Annotate `auc:eGRIDRegionCode` with a deprecation warning. 18 | As a breaking change for 3.0, we will replace `auc:eGRIDRegionCode` with `auc:eGRIDSubregionCodes`. 19 | 20 | ## References 21 | The EPA's online [Power Profiler Tool](https://www.epa.gov/egrid/power-profiler#/CAMX) 22 | The Excel version of the [Power Profiler Zipcode Tool](https://epa.gov/sites/production/files/2020-03/power_profiler_zipcode_tool_2018_3_09_20._v9.xlsx) which has ~8% of the zip codes with a second eGRID subregion and ~0.3% with a third subregion 23 | -------------------------------------------------------------------------------- /proposals/2021/Fix Implement hot aisle cold aisle design.md: -------------------------------------------------------------------------------- 1 | # Fix Implement hot aisle cold aisle design 2 | 3 | ## Overview 4 | 5 | This proposal is to fix the typo in enumeration `Implement hot aisle cold aisle design` under element `auc:DataCenterImprovements`. 6 | 7 | ## Justification 8 | 9 | Currently in version 2.4, the enumeration is mistakenly written as `Implement hot aisle hold aisle design`. To avoid breaking change, we will add the correct enumeration in version 2.5 and delete the wrong one in version 3.0. 10 | 11 | ## Implementation 12 | Add enumeration `Implement hot aisle cold aisle design` under element `auc:DataCenterImprovements`. 13 | 14 | ## References 15 | -------------------------------------------------------------------------------- /proposals/2022/Add DiscountRate.md: -------------------------------------------------------------------------------- 1 | # Add Discount Rate 2 | 3 | ## Overview 4 | 5 | This proposal is support the assertion of discount rates in BuildingSync XML schema. 6 | 7 | ## Justification 8 | 9 | ### Present Value Calculation 10 | 11 | The equation for net present value is: 12 | 13 | $$ NPV\left({i,N}\right) = \sum_{t=0}^{N}{\frac{R_{t}}{\left({1+i}\right)^t}} $$ 14 | 15 | where 16 | * $i$ is the discount rate (percentage). 17 | * $N$ is the total number of periods (non-negative integer). 18 | * $t$ is the time of the cash flow (non-negative integer). 19 | * $R_{t}$ is the cash flow at time $t$ (decimal). 20 | 21 | Currently, BuildingSync XML schema supports the assertion of discount factors via the `` element, where the discount factor $v$ is related to the discount rate $i$ by the following equation: 22 | 23 | $$ v = \frac{1}{1 + i} $$ 24 | 25 | ### Service Life 26 | 27 | BuildingSync XML schema supports the assertion of the service life in years via the `` element. 28 | Currently, the datatype is `xsd:decimal`, which allows for fractional and negative years. 29 | However, ASHRAE [reports](http://weblegacy.ashrae.org/publicdatabase/) median life in non-negative integer years. 30 | 31 | ## Implementation 32 | 33 | The proposed implementation consists of 3 tasks: 34 | 35 | 1. Add `` element (non-breaking change). 36 | 2. Add documentation to definitions of `` and `` elements to clarify their mathematical relationship (non-breaking change). 37 | 3. Constrain datatype of `` element to `xsd:nonNegativeInteger` (breaking change). 38 | -------------------------------------------------------------------------------- /proposals/2022/Add Emissions for MeasureSavingsAnalysis and AnnualSavingsByFuel Elements.md: -------------------------------------------------------------------------------- 1 | # Add Emissions Fields to `MeasureSavingsAnalysis` and `AnnualSavingsByFuel` Elements 2 | 3 | ## Overview 4 | 5 | This proposal is to add Carbon emissions-related fields to the `MeasureSavingsAnalysis` and `AnnualSavingsByFuel` elements. 6 | 7 | ## Justification 8 | 9 | In 2022, [new fields were added to the schema](https://github.com/BuildingSync/schema/blob/develop-v2/proposals/2022/Add%20Emissions.md) to enable the exchange of Carbon emissions data for energy savings packages, resource uses, and time series data points. 10 | The new fields for energy savings packages enable the exchange of **net** Carbon emissions savings data for the package **as a whole** (i.e., not for individual savings by fuel source or for individual measures that comprise said package). 11 | 12 | ### Measure-level Emissions 13 | 14 | The `//Measure/MeasureSavingsAnalysis` element is defined for energy savings measures. 15 | 16 | The `MeasureSavingsAnalysis` element does not have `AnnualSavingsAverageGHGEmissions`, `AnnualSavingsMarginalGHGEmissions`, and `AnnualSavingsGHGEmissionIntensity` child elements. 17 | 18 | ### Fuel-source-level Emissions 19 | 20 | The `//PackageOfMeasures/AnnualSavingsByFuel` and `//Measure/MeasureSavingsAnalysis/AnnualSavingsByFuel` elements are defined for energy savings packages and measures, respectively. 21 | 22 | The `AnnualSavingsByFuel` element does not have `AnnualSavingsAverageGHGEmissions`, `AnnualSavingsMarginalGHGEmissions`, and `AnnualSavingsGHGEmissionIntensity` child elements. 23 | 24 | ## Implementation 25 | 26 | ### Measure-level Emissions 27 | 28 | ```xml 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | ``` 41 | 42 | ### Fuel-source-level Emissions 43 | 44 | ```xml 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | ``` 57 | -------------------------------------------------------------------------------- /proposals/2022/Add Equipment ID.md: -------------------------------------------------------------------------------- 1 | # Add Equipment ID 2 | 3 | ## Overview 4 | 5 | This proposal is to add an "Equipment ID" element to the schema. 6 | 7 | ## Justification 8 | 9 | The schema has an "ID" attribute for each top-level plant/system type; however, the IDs themselves are opaque (i.e., their values can be tested for equality, but otherwise, convey no information) and are locally-unique to the XML document (i.e., their values are only unique within the scope of the XML document). Hence, the "ID" attribute can be used to *identify* and *reference* an element, but not to *name* said element. 10 | 11 | The schema has elements to describe the equipment manufacturer, the year of manufacture, and the model number; however, there is no element for the equipment ID (e.g., "AHU-1", "PTAC-Room-42", or "ABC123"). 12 | 13 | ## Implementation 14 | 15 | This proposal is implemented by adding a new element: 16 | 17 | ```xml 18 | 19 | 20 | Identifier for the equipment. 21 | 22 | 23 | ``` 24 | 25 | The new element is added to the `` for the following types: 26 | 27 | * `` 28 | * `` 29 | * `` 30 | * `` 31 | * `` 32 | * `` 33 | * `` 34 | * `` 35 | * `` 36 | * `` 37 | * `` 38 | * `` 39 | * `` 40 | * `` 41 | * `` 42 | * `` 43 | * `` 44 | * `` 45 | * `` 46 | * `` 47 | * `` 48 | * `` 49 | * `` 50 | * `` 51 | * `` 52 | 53 | The types, above, were identified programmatically using the following XPath: `//xs:complexType[xs:sequence/xs:element[@ref = "auc:Manufacturer"]]`. 54 | -------------------------------------------------------------------------------- /proposals/2022/Add Package-Measure Energy Savings Analyses.md: -------------------------------------------------------------------------------- 1 | # Add Package-Measure Energy Savings Analyses 2 | 3 | ## Overview 4 | 5 | Currently, BuildingSync XML schema supports the exchange of (standalone) package- and measure-level energy savings analysis data, but it does not support the exchange of (contextual) package-measure-level energy savings analysis data. 6 | 7 | This proposal is to add elements to the schema to support the exchange of package-measure-level energy savings analysis data. 8 | 9 | ## Justification 10 | 11 | The term "package-level" refers to data that are intrinsic to the package of measures. 12 | For a given `` element, package-level energy savings analysis data are exchanged using the `` child element. 13 | 14 | The interpretation of package-level energy savings analysis data is that said data applies to the package of measures as a whole (i.e., the net savings for all measures of said package). 15 | 16 | The term "measure-level" refers to data that are intrinsic to the measure. 17 | For a given `` element, measure-level energy savings analysis data are exchanged using the `` child element, which includes a `` child element. 18 | 19 | The interpretation of measure-level energy savings analysis data is that said data applies to the measure as a whole (i.e., not in the context of any specific package of measures). 20 | 21 | ### Example 22 | 23 | Suppose that we have 2 arbitrary measures, #1 and #2. 24 | Implementation of the first measure (as a whole) would cost $100 and would provide electricity savings only. 25 | Implementation of the second measure (as a whole) would cost $200 and would provide natural gas savings only. 26 | 27 | | Measure ID | Cost ($) | Electricity Savings (kWh/yr) | Natural Gas Savings (therms/yr) | 28 | | - | - | - | - | 29 | | #1 | 100 | 50 | 0 | 30 | | #2 | 200 | 0 | 100 | 31 | | **Total:** | 300 | 50 | 100 | 32 | 33 | Suppose that we have 1 arbitrary package, #1, that includes measures #1 and #2. 34 | When purchased together, the vendor offers a $25 discount on measure #1. 35 | Moreover, when implemented with measure #2, measure #1 also provides an additional electricity saving of 25 kWh per year. 36 | 37 | Hence, at the package-level, we have the following data: 38 | 39 | | Package ID | Measure IDs | Cost ($) | Electricity Savings (kWh/yr) | Natural Gas Savings (therms/yr) | 40 | | - | - | - | - | - | 41 | | #1 | #1, #2 | 275 | 75 | 100 | 42 | 43 | The above table conveys both the discount and the additional electricity savings, but it does not attribute the discount or the additional electricity savings to a specific measure (or measures). 44 | 45 | The data are different when the measure is considered standalone or in the context of a specific package, and hence, at the package-measure-level, we have the following data: 46 | 47 | | Measure ID | Package ID | Cost ($) | Electricity Savings (kWh/yr) | Natural Gas Savings (therms/yr) | 48 | | - | - | - | - | - | 49 | | #1 | #1 | 75 | 75 | 0 | 50 | | #2 | #1 | 200 | 0 | 100 | 51 | | | **Total:** | 275 | 75 | 100 | 52 | 53 | ## Implementation 54 | 55 | BuildingSync XML schema supports the many-to-many association of packages and measures using the `` element. 56 | 57 | This proposal is to promote the `` element to the top-level (instead of its definition being inlined) and then to add the `` element as a child element of the `` element. 58 | 59 | ```xml 60 | 61 | 62 | ID numbers for measures included in the package. Multiple items may be selected. 63 | 64 | 65 | 66 | 67 | 68 | ID number of measure. 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | ``` 82 | 83 | **Question for reviewers:** 84 | Are there other elements that would make sense to assert on the relationship (e.g., ``, ``, ``, etc.)? 85 | -------------------------------------------------------------------------------- /proposals/2022/Add RCx Auditor Qualification Types.md: -------------------------------------------------------------------------------- 1 | # Add RCx Auditor Qualification Types 2 | 3 | ## Overview 4 | 5 | This proposal is to add new enumerations to the `` element for retrocommissioning (RCx) auditor qualification types and then to sort the enumerations in alphabetical order. 6 | 7 | ## Justification 8 | 9 | The current definition of the `` element does not define enumerations for RCx. 10 | 11 | Sorting in alphabetical order will make it easier to add new enumerations in future. 12 | 13 | ## Implementation 14 | 15 | This proposal is to: 16 | 1. Add the following enumerations to the `` element: 17 | * AABC Commissioning Group (ACG) Commissioning Authority (CxA) 18 | * Building Commissioning Association (BCA) Certified Commissioning Professional (CCP) 19 | * Building Commissioning Certification Board (BCCB) Certified Commissioning Professional (CCP) 20 | * MEP Professional Engineer 21 | * National Environmental Balancing Bureau (NEBB) Building Systems Commissioning (BSC) 22 | * University of Wisconsin Accredited Commissioning Process Authority Professional (CxAP or CAP) 23 | * University of Wisconsin Accredited Commissioning Process Manager (CxM) 24 | * University of Wisconsin Accredited Green Commissioning Process Provider (GCxP or GCP) 25 | 2. Sort the enumerations in the `` element in alphabetical order. 26 | -------------------------------------------------------------------------------- /proposals/2022/BuildingSync Project Haystack Example.md: -------------------------------------------------------------------------------- 1 | # BuildingSync Project Haystack Example 2 | 3 | The examples below demonstrate an implementation for connecting a BuildingSync model (.xml) to a [Project Haystack](https://project-haystack.org/) model (.json). The examples are _not_ valid schema representations and are shortened to highlight the relevant common elements and entities. 4 | 5 | ## BuildingSync 6 | 7 | The BuildingSync XML below contains three _new_ high-level elements under the `` element that describe details of the metadata ontology or schema. These elements are placed here to accomodate multiple buildings on a single site that may use different metadata schemas, e.g. Brick, Haystack, and ASHRAE 223. 8 | 9 | The XML also contains one _new_ low-level element `` showing an example connection to a Haystack entity, shown below. 10 | 11 | ```xml 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | ... 21 | 860d52bd-9f0e-4986-8644-866bcb24d480 22 | Project Haystack 23 | 3.0 24 | ... 25 | 26 | 27 | 28 | BuildingSync Packaged Rooftop Heat Pump 29 | 9d7b67cb-e07d-4f07-98b2-08f3c6df0400 30 | 31 |
32 | 33 |
34 | 35 | 36 | ... 37 | ``` 38 | 39 | ## Project Haystack 40 | 41 | The Project Haystack JSON below shows an example entity with a common ID to connect to the `` BuildingSync element. 42 | 43 | ```json 44 | { 45 | "_kind": "grid", 46 | "meta": {"ver":"3.0", "doc":"Example of a possible way to connect BuildingSync and Project Haystack."}, 47 | "cols": [ 48 | {"name":"id"}, 49 | ... 50 | ] 51 | "rows":[ 52 | ... 53 | { 54 | "id": "9d7b67cb-e07d-4f07-98b2-08f3c6df0400", 55 | "dis": "Project Haystack Packaged Rooftop Heat Pump", 56 | "ahu": "m", 57 | "equip": "m", 58 | }, 59 | ... 60 | ] 61 | } 62 | ``` 63 | -------------------------------------------------------------------------------- /proposals/2023/Add AuditCycles.md: -------------------------------------------------------------------------------- 1 | # Add AuditCycles 2 | 3 | ## Overview 4 | 5 | This proposal is to add new elements related to Audit Cycle definitions: 6 | * `auc:AuditCycles` 7 | * `auc:AuditCycles/auc:AuditCycle` 8 | * `auc:AuditCycles/auc:AuditCycle/auc:AuditCycleName` 9 | * `auc:AuditCycles/auc:AuditCycle/auc:AuditCycleNotes` 10 | * `auc:AuditCycles/auc:AuditCycle/auc:AuditCycleStartYear` 11 | * `auc:AuditCycles/auc:AuditCycle/auc:AuditCycleEndYear` 12 | under `auc:Facility`, following EISA 432 requirements and for the CERL use case. And add 13 | * `auc:LinkedAuditCycles` 14 | * `auc:LinkedAuditCycles/auc:LinkedAuditCycle` 15 | * `auc:LinkedAuditCycles/auc:LinkedAuditCycle/auc:IndexYearOfAuditCycle` 16 | under `auc:Report`. 17 | An `ID` is required for each `auc:AuditCycle`, and it should be referred via `auc:LinkedAuditCycles/auc:LinkedAuditCycle`. 18 | 19 | ## Justification 20 | 21 | Audit Cycle is defined for CERL use case by EISA 432(?). In Audit Template, an audit cycle is defined with `Name`, `Start year` and `End year`, and `Year of Audit Cycle` is used to identify the number of year in which the audit is conducted within the cycle. Multiple cycles could co-exist and overlap within one report (e.g. a city may have separate cycles for different types of buildings) and the `Name` is used to distinguish. 22 | We will add `auc:AuditCycles` element under `auc:Facility` and allow multiple child elements of `auc:AuditCycle` for each cycle. For each `auc:AuditCycle`, `ID` attribute is required, and `auc:AuditCycleName`, `auc:AuditCycleNotes`, `auc:AuditCycleStartYear`, `auc:AuditCycleEndYear` are child elements. We will add `auc:LinkedAuditCycles/auc:LinkedAuditCycle` under `auc:Report` to link to an associated `auc:AuditCycle` through `IDref`. 23 | 24 | ## Implementation 25 | Under `auc:Facility`: 26 | ```xml 27 | 28 | 29 | ... 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | ... 38 | ``` 39 | Global definition: 40 | ```xml 41 | ... 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | ... 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | ... 74 | ``` 75 | Under `auc:Report`: 76 | ```xml 77 | 78 | 79 | ... 80 | 81 | ... 82 | ``` 83 | -------------------------------------------------------------------------------- /proposals/2023/Add Auditor Certification Types.md: -------------------------------------------------------------------------------- 1 | # Add Auditor Certification Types 2 | 3 | ## Overview 4 | 5 | This proposal is to add new enumerations to the `auc:AuditorCertificationType` element for designations/qualifications from the following organizations: 6 | 7 | * [Building Owners and Managers Institute (BOMI)](https://www.bomi.org/DesignationPrograms.aspx) 8 | * [International Facility Management Association (IFMA)](https://www.ifma.org/credentials/overview/) 9 | * [DOE-recognized programs](https://betterbuildingssolutioncenter.energy.gov/workforce/participating-certifying-organizations) 10 | 11 | ## Justification 12 | 13 | The designations/qualifications were requested by the city of Brisbane, CA, as part of the development of their new audit report template in the [Audit Template](https://buildingenergyscore.energy.gov/) tool. 14 | 15 | ## Implementation 16 | 17 | Add the following enumerations to the `auc:AuditorCertificationType` element: 18 | 19 | 1. Building Owners and Managers Institute (BOMI) International - Facilities Management Administrator (FMA) 20 | 2. Building Owners and Managers Institute (BOMI) International - High-Performance Sustainable Building Management (BOMI-HP) 21 | 3. Building Owners and Managers Institute (BOMI) International - Real Property Administrator (RPA) 22 | 4. Building Owners and Managers Institute (BOMI) International - System Maintenance Administrator (SMA) 23 | 5. Building Owners and Managers Institute (BOMI) International - System Maintenance Technician (SMT) 24 | 6. Energy Management Association (EMA): Energy Management Professional (EMP) 25 | 7. International Facility Management Association (IFMA) Certified Facilities Manager (CFM) 26 | 8. International Facility Management Association (IFMA) Facility Management Professional (FMP) 27 | 9. International Facility Management Association (IFMA) Sustainability Facility Professional (SFP) 28 | 10. National Environmental Balancing Bureau (NEBB) Commissioning Process Professional (CxPP) 29 | -------------------------------------------------------------------------------- /proposals/2023/Add CondenserType.md: -------------------------------------------------------------------------------- 1 | # Add CondenderType 2 | 3 | ## Overview 4 | 5 | This proposal is to add the element `auc:CondenserType` element under `auc:CoolingPlant`. 6 | 7 | ## Justification 8 | 9 | Currently in BuildingSync, a `CondenserPlant` is required to be declared when a `CoolingPlant/Chiller` is defined and should be linked to the `Chiller` through `Chiller/CondenserPlantIDs/CondenserPlantID`. The `CondenserPlant` shares the same level as the `CoolingPlant`, as a component of `Plants`. However, the Audit Template Tool requires this element declared under a `CoolingPlant` for mappinig. 10 | 11 | ## Implementation 12 | The `auc:CondenserType` element will be added as a direct child of `auc:CoolingPlant` with enumerations of "Air Cooled", "Water Cooled", "Other" and "Unknown". 13 | -------------------------------------------------------------------------------- /proposals/2023/Add FacilityEvaluationAuditDefinition.md: -------------------------------------------------------------------------------- 1 | # Add FacilityEvaluationAuditDefinition 2 | 3 | ## Overview 4 | 5 | This proposal is to add new element `auc:FacilityEvaluationAuditDefinition` under `auc:Report` with child elements and enumerations: 6 | * `auc:BasicOnsiteAudit` 7 | * * ASHRAE Level 1 Audit 8 | * * Industrial Assessment Center (IAC) Audit 9 | * * Utility Incentive Program Audit 10 | * `auc:DetailedOnsiteAudit` 11 | * * ASHRAE Level 2 Audit 12 | * * ASHRAE Level 3 Audit 13 | * * Deep Energy Retrofit Audit 14 | * * Preliminary Assessment (PA) 15 | * * Investment Grade Audit (IGA) 16 | * * Retro-Commissioning Audit 17 | * `auc:BasicRemoteAudit` 18 | * * Rapid/Automated Audit 19 | * * Continuous Monitoring of Building Systems 20 | * * Portfolio Screening Analysis 21 | * `auc:DetailedRemoteAudit` 22 | * * Desk Audit 23 | * * Remote Controls Audit 24 | 25 | ## Justification 26 | 27 | The “Facility Evaluation (Audit) Definition” field is a set of categorized enumerations that is defined by FEMP and added in Audit Template. The two layers of categories (Onsite vs. Remote, Basic vs. Detailed) are combined to simplify the structure of the new element. 28 | 29 | ## Implementation 30 | ```xml 31 | 32 | 33 | The facility audit terms used in the FEMP Facility Evaluation (Audit) resources that satisfy EISA 432 requirements 34 | 35 | 36 | 37 | 38 | 39 | A basic onsite audit meets the minimum requirements for onsite facility evaluations 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | A more in-depth facility evaluation that is performed when project development is the focus and a more precise LCCA is required 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | A facility evaluation performed without a site visit and analysis of datasets from specific building systems or operations to derive opportunities for energy efficiency, water efficiency, and renewable energy generation 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | A facility evaluation performed without a site visit and rigorous analysis of building systems and operations to identify opportunities for energy efficiency, water efficiency, and renewable energy generation 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | ``` 91 | 92 | ## References 93 | [FEMP working draft](https://www.energy.gov/femp/articles/femp-facility-evaluation-audit-definitions#:~:text=An%20evaluation%20with%20a%20site,the%20discretion%20of%20the%20Agency%22) 94 | -------------------------------------------------------------------------------- /proposals/2023/Add Measures for Data Center Energy Conservation Improvements.md: -------------------------------------------------------------------------------- 1 | # Add Measures for Data Center Energy Conservation Improvements 2 | 3 | ## Overview 4 | 5 | This proposal is to add new enumerations to the `auc:MeasureName` child element of the `auc:DataCenterImprovements` element for data center energy conservation improvements. 6 | 7 | ## Justification 8 | 9 | The measures were requested by the city of Denver, CO, as part of the development of their new audit report template in the [Audit Template](https://buildingenergyscore.energy.gov/) tool. 10 | 11 | ## Implementation 12 | 13 | Add the following enumerations to the `auc:MeasureName` child element of the `auc:DataCenterImprovements` element: 14 | 15 | 1. Eliminate redundant power supplies 16 | 2. Install battery storage 17 | 3. Replace inefficient hardware 18 | -------------------------------------------------------------------------------- /proposals/2023/Add PrincipalLightingSystemType.md: -------------------------------------------------------------------------------- 1 | # Add PrincipalLightingSystemType 2 | 3 | ## Overview 4 | 5 | This proposal is to add the element `auc:PrincipalLightingSystemType` element under the `auc:Building` and `auc:Section` element. 6 | 7 | ## Justification 8 | 9 | The Audit Template Tool requires this element living directly under building and section level. Due to the hierarchy structural difference between AT and BS, AT can not map `auc:LampType` to their Principal Lighting System Type field under Building or Section, so previously a UDF was used for this. However adding this element does not align with the current structure of BuildingSync, which separates `auc:Facilities` and `auc:Systems` and applies relationship via linking elements - it introduces a "system" element into the `auc:Facilities`. 10 | 11 | ## Implementation 12 | Add the element `auc:PrincipalLightingSystemType` globally, and refer it under `auc:Building` and `auc:Section`. 13 | The enumerations of the added elements are combined by sources from Audit Template library and the child elements of `auc:LampType`. 14 | From Audit Template: 15 | * Compact Fluorescent 16 | * Halogen 17 | * Incandescent 18 | * LED 19 | * Mercury Vapor 20 | * Metal Halide 21 | * Sodium Vapor High Pressure 22 | * T5 23 | * T5HO 24 | * T8 25 | * Super T8 26 | * T12 27 | * T12HO 28 | From `auc:LampType`: 29 | * Incandescent 30 | * Linear Fluorescent 31 | * Compact Fluorescent 32 | * Halogen 33 | * High Intensity Discharge 34 | * Solid State Lighting 35 | * Induction 36 | * Neon 37 | * Plasma 38 | * Photoluminescent 39 | * SelfLuminous 40 | * Other 41 | * Unknown 42 | The combined options might have overlaps (e.g. LED and Solid State Lighting). 43 | 44 | ## Decision 45 | We add this element to avoid the usage of UDF for a commonly used element in AT and improve the data transferability between AT and BuildingSync. However we don't recommend the usage of this element other than the use case of input/output to/from Audit Template. 46 | 47 | ## References 48 | -------------------------------------------------------------------------------- /proposals/2023/Add WCMs to existing Measure Categories.md: -------------------------------------------------------------------------------- 1 | # Add WCM Categories 2 | 3 | ## Overview 4 | 5 | This proposal is to add new water conservation measure enumerations for existing categories under `auc:Measure/auc:TechnologyCategories/auc:TechnologyCategory`. 6 | 7 | ## Justification 8 | 9 | Based on discussion with FEMP on Water Conservation Measure from [WCM resources](https://www.energy.gov/femp/water-efficient-technology-opportunities) and PNNL measure development team on measure formatting, BuildingSync proposed to add various WCMs (and a few ECMs) to the existing measure categories. The categories and new measures are: 10 | ### BoilerPlantImprovements 11 | - Add boiler automatic chemical feed system 12 | - Install boiler condensate return system 13 | - Install boiler automatic blowdown system 14 | - Install boiler blowdown heat exchanger (ECM) 15 | - Install boiler expansion flash tank (ECM) 16 | - Install meters on boiler make-up lines 17 | - Install dehumidification system (ECM) 18 | ### ChilledWaterHotWaterAndSteamDistributionSystems 19 | - Install leak detection system 20 | ### ChillerPlantImprovements 21 | - Implement advanced cooling tower controls to manage cycles of concentration 22 | - Install cooling tower water treatment system 23 | - Install automated chemical feed systems for cooling tower management 24 | - Install conductivity controller for cooling tower management 25 | - Install covers on open distribution decks on top of cooling tower 26 | - Install flow meters on make-up and blowdown lines for cooling tower management 27 | - Install side-stream filtration system for cooling tower management 28 | ### OtherHVAC 29 | - Retrofit single-pass cooling with an automatic shut-off device 30 | - Retrofit single-pass cooling with closed loop/recirculation system 31 | - Install water-efficient evaporative cooler 32 | - Replace water-cooled equipment with air-cooled equipment 33 | ### WaterAndSewerConservationSystems 34 | - Remove water softeners with timers 35 | - Install high-efficiency faucet aerator in lavatory public restrooms 36 | - Install WaterSense-qualified faucet aerator in lavatory private restrooms 37 | - Install WaterSense-qualified showerhead 38 | - Install WaterSense-qualified flushometer toilets 39 | - Install WaterSense-qualified tank toilets 40 | - Install WaterSense-qualified flushing urinal 41 | - Install leak detection system 42 | - Install temporary shut-off or foot-operated valves with kitchen faucets 43 | 44 | ## Implementation 45 | The enumerations will be added in the way identical to the existing measures in the hierarchy of 46 | `auc:Measure` 47 | `auc:TechnologyCategories` 48 | `auc:TechnologyCategory` 49 | `auc:` 50 | `auc:MeasureName` 51 | `[enumerations]`. 52 | -------------------------------------------------------------------------------- /proposals/2023/Update AuditorQualificationType.md: -------------------------------------------------------------------------------- 1 | # Update AuditorQualificationType 2 | 3 | ## Overview 4 | 5 | This proposal is to update a few enumerations under the `auc:AuditorQualificationType` element 6 | 7 | ## Justification 8 | 9 | The update is to make the format of all the Auditor Certification Types consistent 10 | 11 | ## Implementation 12 | 13 | Changes that need to be made are: 14 | 15 | 1. "Association of Energy Engineers Certified Building Commissioning Firm Program (CBCF)" to "Association of Energy Engineers Certified Building Commissioning Firm (CBCF)" 16 | 2. "MEP Professional Engineer" to "Mechanical, Electrical and Plumbing (MEP) Professional Engineer (PE)" 17 | 3. "NYSERDA FlexTech Consultant" to "New York State Energy Research and Development Authority (NYSERDA) FlexTech Consultant" 18 | -------------------------------------------------------------------------------- /proposals/2023/Update PrincipalHVACSystemType.md: -------------------------------------------------------------------------------- 1 | # Update PrincipalHVACSystemType 2 | 3 | ## Overview 4 | 5 | This proposal is to update the usage of element `auc:PrincipalHVACSystemType` to be defined under the `auc:Building` and `auc:Section` elements. 6 | 7 | ## Justification 8 | 9 | The Audit Template Tool requires this element living directly under building and section level instead of being referred through `auc:LinkedPremises` with `auc:HVACSystem/auc:PrincipalHVACSystemType`. 10 | 11 | ## Implementation 12 | Change the definition of element `auc:PrincipalLightingSystemType` globally, and refer it under `auc:Building` and `auc:Section`, as well as `auc:HVACSystem` (where we have the element currently). 13 | 14 | ## Decision 15 | We add this element to avoid the usage of UDF for a commonly used element in AT and improve the data transferability between AT and BuildingSync. However we don't recommend the usage of this element under `auc:Building` and `auc:Section` other than the use case of input/output to/from Audit Template. 16 | 17 | ## References 18 | -------------------------------------------------------------------------------- /proposals/2024/Add AuditCycleStartDate and AuditCycleEndDate.md: -------------------------------------------------------------------------------- 1 | # Add AuditCycleStartDate and AuditCycleEndDate 2 | 3 | ## Overview 4 | 5 | This proposal is to add new elements under `AuditCycle`: 6 | * `auc:AuditCycleStartDate` 7 | * `auc:AuditCycleEndDate` 8 | 9 | ## Justification 10 | 11 | The current `AuditCycleStartYear` and `AuditCycleEndYear` elements support only year data, which may not reflect the actual program year informatio, which mostly are from June to June or Oct to Oct. The Audit Template team and CERL use case requested adding more detailed data for audit cycle start and end time information with full date type. This proposal is to add the two new elements `auc:AuditCycleStartDate` and `auc:AuditCycleEndDate` to support date type data. 12 | 13 | ## Implementation 14 | Under `auc:AuditCycles`: 15 | ```xml 16 | 17 | 18 | A period of time in which multiple audits may be conducted 19 | 20 | 21 | 22 | 23 | Date the Audit Cycle starts (CCYY-MM-DD) 24 | 25 | 26 | 27 | 28 | Date the Audit Cycle ends (CCYY-MM-DD) 29 | 30 | 31 | ... 32 | ``` 33 | -------------------------------------------------------------------------------- /proposals/2024/Add new fenestration system measures.md: -------------------------------------------------------------------------------- 1 | # Add new fenestration system measures 2 | 3 | ## Overview 4 | 5 | This proposal is to add new measure enumerations for existing categories under `auc:Measure/auc:TechnologyCategories/auc:TechnologyCategory/auc:BuildingEnvelopeModifications`. 6 | 7 | ## Justification 8 | 9 | Responding to the request of adding new measures into BuildingSync related to window/shading retrofit, by PNNL/LBNL collaborative Commercial Building and Window Assessment projects, BuildingSync proposed to add two new measures (enumerations) to the existing measure category `BuildingEnvelopeModifications`, which covers measures implemented on fenestration (window/shading) systems. The proposed measures are: 10 | 11 | - Add secondary window systems/attachments 12 | - Install shading automation system 13 | 14 | ## Implementation 15 | The enumerations will be added as in this structure: 16 | `auc:Measure` 17 | `auc:TechnologyCategories` 18 | `auc:TechnologyCategory` 19 | `auc:` 20 | `auc:MeasureName` 21 | `[enumerations]`. 22 | -------------------------------------------------------------------------------- /proposals/2025/Add Optional Elements to All Assets.md: -------------------------------------------------------------------------------- 1 | # Add Optional Elements to All Assets 2 | 3 | ## Overview 4 | 5 | In BuildingSync XML schema, the following optional `xs:element`s are defined for almost all `xs:complexType`s for “assets” (plants, systems, units of equipment, etc.): 6 | 7 | * EquipmentCondition 8 | * EquipmentID 9 | * LinkedPremises 10 | * Location 11 | * Manufacturer 12 | * ModelNumber 13 | * PrimaryFuel 14 | * Quantity 15 | * ThirdPartyCertification 16 | * UserDefinedFields 17 | * YearInstalled 18 | * YearOfManufacture 19 | 20 | The use case for the definition of these optional `xs:element`s is asset tracking and management. They include, but are not limited to, the manufacturer name, year of manufacture, model number, and tag for the asset, along with its year of installation, location, and condition. They also include BuildingSync-specific `xs:element`s for linking the asset to premises that it serves and for representing software-specific, user-defined fields. 21 | 22 | This proposal is to add these optional `xs:element`s to the `xs:complexType`s for all assets. 23 | 24 | The changes that are recommended by this proposal are non-breaking because all the `xs:element`s are optional (viz., `minOccurs="0"`). 25 | 26 | ## Justification 27 | 28 | The following table shows which optional `xs:element`s are currently defined for each `xs:complexType`: 29 | 30 | | |EquipmentCondition|EquipmentID|LinkedPremises|Location|Manufacturer|ModelNumber|PrimaryFuel|Quantity|ThirdPartyCertification|UserDefinedFields|YearInstalled|YearOfManufacture| 31 | |-|-|-|-|-|-|-|-|-|-|-|-|-| 32 | |AirInfiltrationSystem|N|N|Y|N|N|N|N|N|N|Y|N|N| 33 | |AntiSweatHeaters|N|Y|N|N|Y|Y|N|N|N|N|N|N| 34 | |CeilingSystemType|N|N|N|N|N|N|N|Y|N|Y|Y|N| 35 | |CondenserPlantType|Y|N|N|Y|N|N|Y|N|N|Y|Y|N| 36 | |ConveyanceSystemType|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 37 | |CookingSystemType|N|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 38 | |CoolingPlantType|Y|N|N|Y|N|N|Y|N|N|Y|Y|N| 39 | |CoolingSource|Y|Y|N|Y|Y|Y|Y|Y|Y|Y|Y|Y| 40 | |CriticalITSystemType|N|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 41 | |Delivery|Y|Y|N|N|Y|Y|Y|Y|Y|N|Y|Y| 42 | |DishwasherSystemType|N|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 43 | |DomesticHotWaterSystemType|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 44 | |DuctSystemType|N|N|Y|Y|Y|Y|N|Y|N|Y|Y|Y| 45 | |ExteriorFloorSystemType|N|N|N|N|N|N|N|Y|N|Y|Y|N| 46 | |FanSystemType|N|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 47 | |FenestrationSystemType|N|Y|N|N|Y|Y|N|Y|Y|Y|Y|N| 48 | |FoundationSystemType|N|N|N|N|N|N|N|Y|N|Y|Y|N| 49 | |HVACSystemType|N|N|Y|Y|N|N|N|Y|N|Y|N|N| 50 | |HeatRecoverySystemType|N|Y|N|Y|Y|Y|N|Y|Y|Y|Y|Y| 51 | |HeatingPlantType|Y|N|N|Y|N|N|Y|N|N|Y|Y|N| 52 | |HeatingSource|Y|Y|N|Y|Y|Y|Y|Y|N|Y|Y|Y| 53 | |LaundrySystemType|N|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 54 | |LightingSystemType|N|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 55 | |MotorSystemType|N|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 56 | |OnsiteStorageTransmissionGenerationSystemType|N|Y|Y|Y|Y|Y|N|Y|Y|Y|Y|Y| 57 | |OtherHVACSystemType|Y|Y|Y|Y|Y|Y|Y|Y|N|Y|Y|Y| 58 | |PlugElectricLoadType|N|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 59 | |PoolType|N|Y|Y|Y|Y|Y|N|Y|Y|Y|Y|N| 60 | |ProcessGasElectricLoadType|N|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 61 | |PumpSystemType|N|Y|N|Y|Y|Y|Y|Y|Y|Y|Y|Y| 62 | |RefrigerationSystemType|N|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y|Y| 63 | |RoofSystemType|N|N|N|N|N|N|N|Y|N|Y|Y|N| 64 | |WallSystemType|N|N|N|N|N|N|N|Y|N|Y|Y|N| 65 | |WaterInfiltrationSystem|N|N|Y|N|N|N|N|N|N|Y|N|N| 66 | |WaterUseType|N|Y|Y|Y|Y|Y|N|Y|Y|Y|Y|Y| 67 | |**Total**|9/35|23/35|20/35|25/35|24/35|24/35|20/35|29/35|20/35|33/35|31/35|21/35| 68 | 69 | ## Implementation 70 | 71 | When they are absent, the optional `xs:element`s are added to the `xs:complexType`s. 72 | -------------------------------------------------------------------------------- /proposals/README.md: -------------------------------------------------------------------------------- 1 | # BuildingSync Feature Proposals 2 | 3 | ## Overview 4 | This document lays out the procedure for the proposal and completion of changes to BuildingSync. The procedure is described in further detail below. The proposal process is initiated with the creation of a document similar to this one. The document is expected to have at least three sections: **Overview**, **Justification**, and **Implementation**. The overview section provides a high-level description of the proposal, the justification section provides evidence that the changes are needed or required, and the implementation section describes how the changes will be implemented. 5 | 6 | ## Justification 7 | BuildingSync is intended to be a standardized language for commercial building energy audit data that software developers can use to exchange data between audit tools. BuildingSync will only continue to provide a standard data specification if there is an open, transparent process by which stakeholders can propose changes to the schema. 8 | 9 | ## Implementation 10 | The process is semi-formal and is not intended to be rigidly applied. The procedure is roughly comprised of the following steps: 11 | 12 | 1. The proposer writes a Markdown document, modeled on this document, that succinctly describes the changes that are proposed. 13 | 2. The proposer creates a GitHub pull request that adds the document to the proposal directory in a subdirectory named for the year in which the submission is being made (e.g. proposals/2018/Add_New_Feature_XYZ.md). 14 | 3. The proposer, the BuildingSync team, and other stakeholders and interested parties discuss the proposal and make modifications using the GitHub pull request discussion facility. At the conclusion of this process, the proposal is accepted or rejected. If a clear consensus cannot be reached to accept or reject the proposal, the project lead will decide if the proposal should be accepted. 15 | 4. If the proposal is accepted, new GitHub issues are created to track the development (or a GitHub Project if it is a larger proposal), and a developer is assigned to the issues (not necessarily the proposer or a BuildingSync team member). The "proposal" pull request is then merged. 16 | 5. The change is made by the developer in accordance with the contribution policy. 17 | 6. The developer initiates a GitHub pull request when the changes are complete. The BuildingSync team and other stakeholders and interested parties will review the implementation and request necessary changes. If consensus can be reached that the implementation is acceptable, the pull request is merged and tracking items are closed. If a clear consensus cannot be reached to accept or reject the implementation, the project lead will decide if the implementation should be accepted. 18 | 19 | The proposal document must contain at least three sections: **Overview**, **Justification**, and **Implementation**. The purpose of each of the sections is as follows: 20 | 21 | * Overview: Provides a brief, high-level summary of the proposed changes. 22 | * Justification: Provides supporting evidence for the changes. The evidence given here must be sufficient to establish that the changes are needed and will provide a benefit to users and/or developers. 23 | * Implementation: Describes the implementation of the changes. If the changes are breaking, discussion of the severity of the breakage is required. 24 | 25 | If needed, additional sections (e.g. **References**) may be added. 26 | 27 | ## References 28 | N/A 29 | -------------------------------------------------------------------------------- /tests/__init__.py: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/BuildingSync/schema/2d1e04c6942ad66aad2af04d5fced082b3c7a141/tests/__init__.py -------------------------------------------------------------------------------- /tests/test_bsync_examples.py: -------------------------------------------------------------------------------- 1 | from bsync_examples import __version__ 2 | 3 | 4 | def test_version(): 5 | assert __version__ == '0.1.0' 6 | --------------------------------------------------------------------------------