Skip to content

Commit 8b38784

Browse files
authored
Merge pull request #221 from BuildingSync/develop
Release 2.2.0-pr1
2 parents 0c060fd + b3635c0 commit 8b38784

13 files changed

+94958
-94047
lines changed

BuildingSync.json

+93,972-93,967
Large diffs are not rendered by default.

BuildingSync.xsd

+258-79
Large diffs are not rendered by default.

CHANGELOG.md

+47-1
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,59 @@
11
# BuildingSync
22

3+
## Version 2.2.0-pr1
4+
5+
BuildingSync Version 2.2.0-pr1 does not introduce any breaking changes. It introduces elements required for
6+
a complete audit report for ASHRAE Standard 211 Level 1.
7+
Note that the element `auc:PrimaryHVACSystemType` is in the process of being deprecated, and users should replace it with
8+
`auc:PrincipalHVACSystemType` to ensure future conformance to the schema.
9+
10+
Date Range: 07/31/20 - 08/31/20
11+
12+
| Category | Count |
13+
|----------------|-------|
14+
| Controls | 0 |
15+
| General | 3 |
16+
| Measures | 0 |
17+
| Reports | 7 |
18+
| Systems | 1 |
19+
| Validation | 0 |
20+
| Other | 1 |
21+
| **Total** | 12 |
22+
23+
| Change Type | Count |
24+
|----------------|-------|
25+
| Breaking Change | 0 |
26+
| Non-breaking Change | 12 |
27+
28+
New Issues: 2 (#212, #218)
29+
30+
Closed Issues: 3
31+
- Merged [#172]( https://github.com/BuildingSync/schema/issues/172 ), Promote UDF - PrincipalHVACType as part of Section.
32+
- Merged [#173]( https://github.com/BuildingSync/schema/issues/173 ), Promote UDF - PrincipalLightingSystemType as part of Section.
33+
- Merged [#212]( https://github.com/BuildingSync/schema/issues/212 ), Question concerning some "Other delivered" auc:FuelTypes
34+
35+
Accepted Pull Requests: 12
36+
- Merged [#200]( https://github.com/BuildingSync/schema/pull/200 ), Add ReadingType Cost to TimeSeries
37+
- Merged [#203]( https://github.com/BuildingSync/schema/pull/203 ), Add ResourceUseNotes to ResourceUse
38+
- Merged [#204]( https://github.com/BuildingSync/schema/pull/204 ), Add AnnualFuelCost to ResourceUse
39+
- Merged [#205]( https://github.com/BuildingSync/schema/pull/205 ), Add SimpleImpactAnalysis and CostCategory to PackageOfMeasures
40+
- Merged [#207]( https://github.com/BuildingSync/schema/pull/207 ), Add ExcludedSectionIDs to FloorArea
41+
- Merged [#208]( https://github.com/BuildingSync/schema/pull/208 ), Add LinkedPremises to Schedule
42+
- Merged [#213]( https://github.com/BuildingSync/schema/pull/213 ), Add AnnualFuelUseLinkedTimeSeriesIDs to ResourceUse
43+
- Merged [#214]( https://github.com/BuildingSync/schema/pull/214 ), Add multiple elements for energy use in AllResourceTotal
44+
- Merged [#215]( https://github.com/BuildingSync/schema/pull/215 ), Add choice between PrimaryHVACSystemType and PrincipalHVACSystemType
45+
- Merged [#216]( https://github.com/BuildingSync/schema/pull/216 ), pull rate elements out as distinct element types to reduce redundancy
46+
- Merged [#217]( https://github.com/BuildingSync/schema/pull/217 ), update tiered rate to include demand rate start and end dates
47+
- Merged [#219]( https://github.com/BuildingSync/schema/pull/219 ), feat(proposals): add proposal for versioning
48+
349
## Version 2.1.0
450

551
BuildingSync Version 2.1.0 does not introduce any breaking changes; however, the `version` attribute is now required
652
as part of the root `BuildingSync` element. Version 2.1.0 includes many validation updates and additions
753
to support reporting auditing data. Also, the release versions now include the patch version (e.g.,
854
major.minor.patch).
955

10-
Date Range: 12/21/19 - 07/31/20
56+
Date Range: 12/21/19 - 07/30/20
1157

1258

1359
| Category | Count |
+40
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
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+
<xs:complexType name="ResourceUseType">
20+
<xs:sequence>
21+
...
22+
<xs:element name="AnnualFuelCost" minOccurs="0" type="xs:string">
23+
<xs:annotation>
24+
<xs:documentation>Annual cost of the resource ($)</xs:documentation>
25+
</xs:annotation>
26+
<xs:complexType>
27+
<xs:simpleContent>
28+
<xs:extension base="xs:decimal">
29+
<xs:attribute ref="auc:Source"/>
30+
</xs:extension>
31+
</xs:simpleContent>
32+
</xs:complexType>
33+
</xs:element>
34+
...
35+
</xs:sequence>
36+
```
37+
38+
## References
39+
40+
Standard 211 6.1.2.1.g and 6.1.2.1.i
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
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+
<auc:Scenario>
22+
<auc:TimeSeriesData>
23+
<auc:TimeSeries>
24+
<auc:ReadingType>Total</auc:ReadingType>
25+
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
26+
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
27+
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
28+
<auc:IntervalReading>123</auc:IntervalReading>
29+
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
30+
</auc:TimeSeries>
31+
<auc:TimeSeries>
32+
<auc:ReadingType>Peak</auc:ReadingType>
33+
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
34+
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
35+
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
36+
<auc:IntervalReading>123</auc:IntervalReading>
37+
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
38+
</auc:TimeSeries>
39+
<auc:TimeSeries>
40+
<!-- Add this type -->
41+
<auc:ReadingType>Cost</auc:ReadingType>
42+
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
43+
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
44+
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
45+
<auc:IntervalReading>1000</auc:IntervalReading>
46+
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
47+
</auc:TimeSeries>
48+
</auc:TimeSeriesData>
49+
</auc:Scenario>
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+
<auc:Scenario>
62+
<auc:TimeSeriesData>
63+
<auc:TimeSeries>
64+
<!-- Add this element -->
65+
<auc:IntervalReading>
66+
<auc:Total>123</auc:Total>
67+
<auc:Peak>123</auc:Peak>
68+
<auc:Cost>1000</auc:Cost>
69+
</auc:IntervalReading>
70+
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
71+
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
72+
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
73+
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
74+
</auc:TimeSeries>
75+
</auc:TimeSeriesData>
76+
</auc:Scenario>
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.
+45
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
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+
<xs:element name="<name here>" minOccurs="0">
34+
<xs:complexType>
35+
<xs:simpleContent>
36+
<xs:extension base="xs:decimal">
37+
<xs:attribute ref="auc:Source"/>
38+
</xs:extension>
39+
</xs:simpleContent>
40+
</xs:complexType>
41+
```
42+
43+
## References
44+
45+
Standard 211 sections 5.2.3 and 5.2.3.1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
# Add occupancy schedule linking
2+
3+
## Overview
4+
5+
This proposal is to address the need of linking a schedule related to occupancy to sections (specifically space functions).
6+
7+
## Justification
8+
9+
Standard 211 6.2.1.1.e states:
10+
> Schedules of **occupant density**, lighting, process and plug loads, and equipment use shall be provided for typical days.
11+
12+
It's been decided these schedules should be specified at the level of space functions.
13+
14+
Currently, there are two patterns for linking schedules to "premises" in BuildingSync
15+
1. Through a system. Most (all?) systems have an `auc:LinkedPremises` element. This provides the ability to link a system to a premise, and _also_ specify the schedule associated (using `auc:LinkedScheduleIDs`)
16+
1. Premise -> schedule linking. For example, in `auc:Space` (in `auc:ThermalZone/auc:Spaces`) BuildingSync allows linking to schedules (related to occupancy) through `auc:OccupancyScheduleIDs`.
17+
18+
Since there's no way to currently link occupancy schedules to sections (space functions), (there is no system which can be used to link it, and there is no `auc:OccupancyScheduleIDs` at the level of `auc:Section`), BuildingSync needs this addition.
19+
20+
## Implementation
21+
22+
### Option 1
23+
Add `auc:OccupancyScheduleIDs` to `auc:Section`
24+
```xml
25+
<auc:Building>
26+
<auc:Sections>
27+
<auc:Section ID="SpaceFunction-A">
28+
<auc:SectionType>Space function</auc:SectionType>
29+
...
30+
<!-- add this element -->
31+
<auc:OccupancyScheduleIDs>
32+
<auc:OccupancyScheduleID IDref="Schedule-Weekdays"/>
33+
<auc:OccupancyScheduleID IDref="Schedule-Weekend"/>
34+
</auc:OccupancyScheduleIDs>
35+
</auc:Section>
36+
</auc:Sections>
37+
</auc:Building>
38+
...
39+
<auc:Schedules>
40+
<auc:Schedule ID="Schedule-Weekdays">
41+
<auc:ScheduleDetails>
42+
<auc:ScheduleDetail>
43+
<auc:DayType>Weekday</auc:DayType>
44+
<auc:ScheduleCategory>Occupied</auc:ScheduleCategory>
45+
<auc:PartialOperationPercentage>80</auc:PartialOperationPercentage>
46+
</auc:ScheduleDetail>
47+
</auc:ScheduleDetails>
48+
</auc:Schedule>
49+
<auc:Schedule ID="Schedule-Weekend">
50+
<auc:ScheduleDetails>
51+
<auc:ScheduleDetail>
52+
<auc:DayType>Weekend</auc:DayType>
53+
<auc:ScheduleCategory>Occupied</auc:ScheduleCategory>
54+
<auc:PartialOperationPercentage>40</auc:PartialOperationPercentage>
55+
</auc:ScheduleDetail>
56+
</auc:ScheduleDetails>
57+
</auc:Schedule>
58+
<auc:Schedules>
59+
```
60+
61+
#### Pros
62+
- non-breaking
63+
- follows pattern of `auc:Spaces`
64+
65+
#### Cons
66+
- only solves specific problem. What if we eventually want to link occupancy schedules to buildings and not spaces?
67+
68+
### Option 2
69+
Add `auc:LinkedPremises` to `auc:Schedule`
70+
```xml
71+
<auc:Building>
72+
<auc:Sections>
73+
<auc:Section ID="SpaceFunction-A">
74+
<auc:SectionType>Space function</auc:SectionType>
75+
...
76+
</auc:Section>
77+
</auc:Sections>
78+
</auc:Building>
79+
...
80+
<auc:Schedules>
81+
<auc:Schedule ID="Schedule-Weekdays">
82+
<auc:ScheduleDetails>
83+
<auc:ScheduleDetail>
84+
<auc:DayType>Weekday</auc:DayType>
85+
<auc:ScheduleCategory>Occupied</auc:ScheduleCategory>
86+
<auc:PartialOperationPercentage>80</auc:PartialOperationPercentage>
87+
</auc:ScheduleDetail>
88+
</auc:ScheduleDetails>
89+
<!-- add this element -->
90+
<auc:LinkedPremises>
91+
<auc:Section>
92+
<auc:LinkedSectionID IDref="SpaceFunction-A"/>
93+
</auc:Section>
94+
<auc:LinkedPremises>
95+
</auc:Schedule>
96+
<auc:Schedule ID="Schedule-Weekend">
97+
<auc:ScheduleDetails>
98+
<auc:ScheduleDetail>
99+
<auc:DayType>Weekend</auc:DayType>
100+
<auc:ScheduleCategory>Occupied</auc:ScheduleCategory>
101+
<auc:PartialOperationPercentage>40</auc:PartialOperationPercentage>
102+
</auc:ScheduleDetail>
103+
</auc:ScheduleDetails>
104+
<!-- add this element -->
105+
<auc:LinkedPremises>
106+
<auc:Section>
107+
<auc:LinkedSectionID IDref="SpaceFunction-A"/>
108+
</auc:Section>
109+
<auc:LinkedPremises>
110+
</auc:Schedule>
111+
<auc:Schedules>
112+
```
113+
114+
#### Pros
115+
- non-breaking
116+
- solves linking of occupancy schedules to any premise type
117+
118+
#### Cons
119+
- could be very confusing if a user sees they can link a schedule through a system, or directly to a premise
120+
- allows users to link a schedule to another schedule, which probably doesn't make any sense
121+
122+
#### Variations
123+
- don't use LinkedPremises, but come up with a new linking element which is basically the same but doesn't allow linking to schedules
124+
125+
## Decision
126+
We are moving forward with Option 2.
127+
128+
## References
129+
130+
Standard 211 6.2.1.1.e
+33
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
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+
<xs:complexType name="ResourceUseType">
19+
<xs:sequence>
20+
...
21+
<xs:element name="ResourceUseNotes" type="xs:string">
22+
<xs:annotation>
23+
<xs:documentation>Notes about the resource use; for example, meter sampling methodology</xs:documentation>
24+
</xs:annotation>
25+
</xs:element>
26+
</xs:sequence>
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

0 commit comments

Comments
 (0)