Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ReadingType Cost to TimeSeries #200

Merged
merged 8 commits into from
Aug 27, 2020
Merged

Add ReadingType Cost to TimeSeries #200

Changes from 4 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
11a9097
feat(propsals): write proposal for timeseries cost
macintoshpie Jul 15, 2020
0815c8b
refactor(proposals): improve timeseries cost proposal
macintoshpie Jul 16, 2020
180d0c3
Merge branch 'develop' into feat/time-series-cost
nllong Jul 17, 2020
7391a4a
chore(proposals): rename proposed element
macintoshpie Jul 20, 2020
a6da452
refactor(proposals): remove undesired options
macintoshpie Jul 20, 2020
762ee60
chore(proposals): add decision to time series cost proposal
macintoshpie Aug 26, 2020
f2a91ee
feat(schema): add Cost for TimeSeries ReadingType
macintoshpie Aug 25, 2020
295e473
Merge branch 'develop' into feat/time-series-cost
macintoshpie Aug 27, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
197 changes: 197 additions & 0 deletions proposals/2020/Add Associated Cost to TimeSeries.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,197 @@
# Add Associated Cost to TimeSeries

## Overview

This proposal is to include a method for associating cost ($) with time series data.

## Justification

The monthly resource use cost is required information per Standard 211 6.1.2.1 (i), which states
> 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**

An important note is that STD 211 requires Total, Peak, and Cost for each Monthly metering interval.

## Implementation

There are multiple options for implementation.

### Option 1
Define a new enum for `auc:ReadingType`, `Cost`, in `auc:TimeSeries`.
```xml
<auc:Scenario>
<auc:TimeSeriesData>
<auc:TimeSeries>
<auc:ReadingType>Total</auc:ReadingType>
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
<auc:IntervalReading>123</auc:IntervalReading>
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
</auc:TimeSeries>
<auc:TimeSeries>
<auc:ReadingType>Peak</auc:ReadingType>
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
<auc:IntervalReading>123</auc:IntervalReading>
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
</auc:TimeSeries>
<auc:TimeSeries>
<!-- Add this type -->
<auc:ReadingType>Cost</auc:ReadingType>
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
<auc:IntervalReading>1000</auc:IntervalReading>
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
</auc:TimeSeries>
</auc:TimeSeriesData>
</auc:Scenario>
```
#### Pros
- non-breaking change
#### Cons
- 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:
1. Find all auc:ReadingType=Cost associated with a ResourceUse
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).

### Option 2
Define a new element `auc:Cost`, in `auc:TimeSeries`.
```xml
<auc:Scenario>
<auc:TimeSeriesData>
<auc:TimeSeries>
<auc:ReadingType>Total</auc:ReadingType>
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
<auc:IntervalReading>123</auc:IntervalReading>
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
<!-- Add this element -->
<auc:Cost>1000</auc:Cost>
</auc:TimeSeries>
<auc:TimeSeries>
<auc:ReadingType>Peak</auc:ReadingType>
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
<auc:IntervalReading>123</auc:IntervalReading>
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
<!-- Add this element -->
<auc:Cost>2000</auc:Cost>
</auc:TimeSeries>
</auc:TimeSeriesData>
</auc:Scenario>
```
#### Pros
- non-breaking change
- easy to get cost associated with a reading
#### Cons
- a cost might be dependent upon multiple reading types, e.g. the cost is associated with both the total use and peak use (that might not be true in the real utility world but it's just an example), and this model is unable to represent that relationship.

### Option 3
Create a new element (maybe in `auc:AllResourceTotals`) that can contain cost and can reference `auc:TimeSeries` IDs.

```xml
<auc:Scenario>
<auc:AllResourceTotals>
<auc:Costs>
nllong marked this conversation as resolved.
Show resolved Hide resolved
<auc:Cost IDref="TimeSeries-Total-January">1000</auc:Cost>
<auc:Cost IDref="TimeSeries-Peak-January">1000</auc:Cost>
</auc:Costs>
</auc:AllResourceTotals>
<auc:TimeSeriesData>
<auc:TimeSeries ID="TimeSeries-Total-January">
<auc:ReadingType>Total</auc:ReadingType>
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
<auc:IntervalReading>123</auc:IntervalReading>
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
</auc:TimeSeries>
<auc:TimeSeries ID="TimeSeries-Peak-January">
<auc:ReadingType>Peak</auc:ReadingType>
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
<auc:IntervalReading>123</auc:IntervalReading>
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
</auc:TimeSeries>
</auc:TimeSeriesData>
</auc:Scenario>
```
#### Pros
- non-breaking change
#### Cons
- finding the cost for a reading is less trivial, and must use IDrefs (ie xpaths a bit of a pain)
- a cost might be dependent upon multiple reading types, e.g. the cost is associated with both the total use and peak use (that might not be true in the real utility world but it's just an example), and this model is unable to represent that relationship.

### Option 4
Change `auc:TimeSeries` to include `auc:IntervalReadings` which could contain multiple reading types.
```xml
<auc:Scenario>
<auc:TimeSeriesData>
<auc:TimeSeries>
<!-- Add this element -->
<auc:IntervalReadings>
nllong marked this conversation as resolved.
Show resolved Hide resolved
<auc:Total>123</auc:Total>
<auc:Peak>123</auc:Peak>
<auc:Cost>1000</auc:Cost>
</auc:IntervalReadings>
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
</auc:TimeSeries>
</auc:TimeSeriesData>
</auc:Scenario>
```
#### Pros
- More concise modeling of meter data required by STD 211
- easy to find associated cost with a reading, and can handle cost that's associated with multiple reading types
#### Cons
- breaking change
- another layer of nesting, which is unnecessary if most people just use it for reporting only one reading type

### Option 5
Kind a hybrid of options 2 and 4, get rid of `auc:ReadingType` and use elements to indicate different readings types.
```xml
<auc:Scenario>
<auc:TimeSeriesData>
<auc:TimeSeries>
<!-- Add these elements -->
<auc:IntervalTotal>123</auc:IntervalTotal>
<auc:IntervalPeak>123</auc:IntervalPeak>
<auc:IntervalCost>1000</auc:IntervalCost>
<auc:StartTimestamp>2019-01-01T00:00:00</auc:StartTimestamp>
<auc:EndTimestamp>2019-02-01T00:00:00</auc:EndTimestamp>
<auc:IntervalFrequency>Month</auc:IntervalFrequency>
<auc:ResourceUseID IDref="ResourceUse-Electricity" />
</auc:TimeSeries>
</auc:TimeSeriesData>
</auc:Scenario>
```
Pros and cons are the same as option 4, this approach just uses less nesting which is nice.

### Option 6
A variation on Option 3
```xml
<auc:AllResourceTotals>
<auc:Costs>
<auc:Cost>
<auc:CostValue>1000</auc:CostValue>
<auc:ResourceUseID IDref="ResourceUse-Electricity"/>
<auc:TimeSeriesIDs>
<auc:TimeSeriesID IDref="TimeSeries-Total-January"/>
<auc:TimeSeriesID IDref="TimeSeries-Peak-January"/>
</auc:TimeSeriesIDs>
</auc:Cost>
<auc:Costs>
</auc:AllResourceTotals>
```
#### Pros
- non-breaking change
- can handle associating a cost with multiple readings

#### Cons
- finding the cost for a reading is less trivial, and must use IDrefs (ie xpaths a bit of a pain)