AMS Data Workshop II: ERCOT AMS Data Monitoring and Processes

  1. AMS Interval Usage vs. 867 Summary Usage Comparison

This reporting seeks to create market transparency on the extent to which 15-minute interval consumption (kWh) is not in synch with 867 summary consumption (kWh).

Sample chart with MADE-UP DATA:

**ILLUSTRATIVE ONLY – DOES NOT REPRESENT ACTUAL OR EXPECTED VALUES**

[Month YYYY]

Known Issues to Address

  • 867 Transactions do not contain a timestamp (only a date) for when the start and end meter reads were taken. Therefore, if a meter read used in an 867 was taken at noon, it will not contain the full day’s usage, which would be included in the interval data. This could lead to marginally inflated reporting of out-of-synch conditions.
  • Scaling due to different sized TDUs. It may make sense to also have a separate chart for each TDU to avoid a dwarfing effect on AEP and TNMP.
  • ERCOT does not currently store the meter multiplier value from 867 transactions. Therefore, it is not currently possible to report out-of-synch occurrences in the context of the applicable meter multiplier.
  • Ideas to consider:
  • Report by AMSM and AMSR (majority of AMSR meters should have meter multiplier of 1)
  • Report by POLR Customer Class or Premise Type
  • Report by Profile Type (there are 28 types)
  • Report synch conditions as a percentage of total usage
  • Timing: monthly or triggered by receipt of 867?
  1. Latency of AMS Data Delivery

This reporting seeks to provide market transparency on the time lapse (“latency”) between an Operating Day and when the interval datafor that Operating Day is receivedat ERCOT.

Sample charts with MADE-UP DATA:

**ILLUSTRATIVE ONLY – DOES NOT REPRESENT ACTUAL OR EXPECTED VALUES**

Interval Data Aging by Date Received

[Month YYYY] – [TDSP NAME]

(If Applicable) REP Name [For REP requested reports]

Description: monthly report that looks at the number of ESI IDs for which LSE data was loaded at ERCOT during the month and shows what operating days that data pertains (excludes data received within OD +2)

Issues to address:

  • Feasibility at ERCOT?
  • Include or exclude “≤OD+2”?

Operating Month Interval Data Latency

[Month YYYY] – [TDSP NAME]

(If Applicable) REP Name [For REP requested reports]

Description: monthly report that is run after true-up settlement and looks at the number of ESI IDs for which LSE data was loaded later than Operating Day + 1.

Issues to address:

  • Feasibility at ERCOT?
  • All data receipts vs. final data receipts?
  • Timing: wait for full true-up settlement, or is final settlement sufficient?

Volumetric Impact of Interval Data Revisions

[Month YYYY] – [TDSP Name]

(If Applicable) REP Name [For REP requested reports]

Description: Monthly report that is run at end of month and looks at all LSE data loaded during the reporting month. Report quantifies kWh received by Operating Day Latency (# of days between OD and receipt of most current LSE data).

Issues to address:

  • Feasibility at ERCOT?
  • ERCOT sees data revisions as replacement of the entire day’s interval data; ERCOT may require system changes to be able to calculate the interval level impact
  • Is volume the best metric for measuring revisions?
  • $ impact on resettlements could help to size the impact, but adds complexity to the analysis