introduction - web viewthe gtl calculation shall form the basis for determining a ba relief...

6/4/2014

Stakeholder

Comments

DRAFT

Enhanced Curtailment Calculator (ECC)Functional Requirements

By

Peak ReliabilityWith support from the ECC Advisory Committee

MMM DD, YYY

ECC Tool Functional Definition

Table of Contents

1 Introduction .................................................................................................................3

1.1 Phase I versus Phase II .......................................................................................4

1.2 What this Document Defines ................................................................................4

1.3 What this Document Does Not Define .................................................................4

2 Inputs, Processes, Outputs and Mechanisms .............................................................6

2.1 Data Flow .............................................................................................................7

2.2 Inputs ...................................................................................................................7

2.2.1 West-Wide System Model (WSM) .............................................................9

2.2.2 SE (State Estimator) Savecase Data ......................................................10

2.2.3 ECC Model ..............................................................................................10

2.2.4 ECC Element Definitions .........................................................................10

2.2.5 Mapping WSM to ECC ............................................................................11

2.2.6 Real-Time Data .......................................................................................11

2.2.7 Scheduled Flow (e-Tags) ........................................................................12

2.2.8 Look-Ahead Data Inputs ..........................................................................13

2.3 ECC Element and Calculations Processes ........................................................13

2.3.1 Element Management Process ...............................................................13

2.3.2 Calculate Shift Factors ............................................................................16

2.3.3 Calculate Element Impacts ......................................................................19

2.4 Outputs & Mechanisms ......................................................................................21

2.4.1 Visualization of Operational Results ........................................................21

2.4.2 User Interface and Displays ....................................................................22

2.4.3 ECC Alarm Processing ............................................................................25

2.4.4 Logging and Reporting ............................................................................25

3 External Access, Controls, and Administration .........................................................26

3.1 Import, Export and API .......................................................................................26

3.2 Security ..............................................................................................................26

3.2.1 User Roles, Rights, and Access ..............................................................26

3.3 ECC Administration ............................................................................................27

3.4 Controls ..............................................................................................................27

4 Performance Metrics .................................................................................................28

P a g e 1


4.1 Performance ......................................................................................................28

4.2 Availability ..........................................................................................................28

4.3 Data Retention ...................................................................................................29

Appendix A: Terms, Acronyms, and Definitions ..........................................................30

1 Introduction .................................................................................................................3

1.1 What this Document Defines ................................................................................4

1.2 What this Document Does Not Define .................................................................4

2 Inputs, Processes, Outputs and Mechanisms .............................................................5

2.1 Data Flow .............................................................................................................6

2.2 Inputs ...................................................................................................................6

2.2.1 West-Wide System Model (WSM) .............................................................8

2.2.2 SE (State Estimator) Savecase Data ........................................................8

2.2.3 ECC Model ................................................................................................9

2.2.4 Real-Time Data .........................................................................................9

2.2.5 ECC Element Definitions .........................................................................10

2.2.6 Scheduled Flow (e-Tags) ........................................................................10

2.2.7 Look-Ahead Data Inputs ..........................................................................10

2.3 Processes ..........................................................................................................11

2.3.1 Element Management Process ...............................................................11

2.3.2 Calculate Shift Factors ............................................................................14

2.3.3 Calculate Element Impacts ......................................................................16

2.4 Outputs & Mechanisms ......................................................................................18

2.4.1 Visualization of Operational Results ........................................................19

2.4.2 User Interface and Displays ................................................................2019

2.4.3 ECC Alarm Processing ............................................................................23

2.4.4 Logging and Reporting ............................................................................23

3 External Access, Controls, and Administration .........................................................23

3.1 Import, Export and API .......................................................................................23

3.2 Security ..............................................................................................................24

3.2.1 User Roles, Rights, and Access ..............................................................24

3.3 ECC Administration ........................................................................................2524

3.4 Controls ..............................................................................................................25

4 Performance Metrics .................................................................................................25

4.1 Performance ......................................................................................................25P a g e 2


4.2 Availability ..........................................................................................................26

4.3 Data Retention ...............................................................................................2726

Appendix A: Terms, Acronyms, and Definitions ..........................................................28

P a g e 3


1 Introduction

This document was developed by Peak RC in consultation with the ECC Task Force Advisory Committee to define minimum functional requirements for the Enhanced Curtailment Calculator tool.

The ECC is envisioned to serve as a congestion management tool used by Reliability Coordinators to manage power system congestion within the Western Interconnection. Peak RC views the ECC as being a reliability tool that can be used in conjunction with other RC reliability tools to ensure acceptable system performance for the Bulk Electric System.

Peak RC, as well as many TOPs in the Western Interconnection, perform Real-time Assessments using a suite of real-time reliability tools to understand how the system is performing on a pre- and post-Contingency basis. These tools generally include SCADA, state estimation, and Real-time Contingency Analysis (RTCA), and may include other advanced applications such as real-time voltage and transient stability analysis. When real-time tools indicate that the system is performing unacceptably pre- or post-Contingency or is trending toward unacceptable performance (i.e., SOL exceedance is occurring or is expected to occur), system operators are expected to take action to prevent or mitigate the condition. This action can take several forms including making adjustments in the uses of the transmission system (i.e., schedule curtailments or adjustments).

Peak Reliability Coordinator System Operators (RCSOs) use a suite of reliability tools to assess pre- and post-Contingency performance. With the addition of the ECC to the RCSO’s toolkit, the RCSOs will not only have increased situational awareness (phase I), but will also have the ability to initiate curtailments necessary to ensure reliability (phase II). The ECC will have the ability to describe and quantify the contributors of flow on ECC defined Elements. The RCSO will use the ECC to determine the cause (source) of these unacceptably high flows that are being observed in the RC’s suite of real-time tools. With this information, the RCSO in collaboration with the TOP or BA can choose to address the reliability issue through local actions or may choose to use the ECC to initiate curtailments necessary to relieve the condition. Any curtailments initiated by the ECC will be done in a fair and equitable manner according to the curtailment methodology and rules programmed into the tool. This methodology and rule set will be addressed under phase II and will undergo a stakeholder vetting process.

The current congestion management tool, WebSAS, is used to manage the impacts of unscheduled flow on the six Transmission Paths that have satisfied the qualification process criteria described in the WECC Unscheduled Flow Mitigation Plan. While the webSAS tool currently manages congestion only on the six qualified paths, the ECC will have the ability to manage congestion on any BES Facility (or grouping of Facilities) in the Western Interconnection through the use of defined ECC Elements. The ECC will have the flexibility to define Elements as necessary to ensure reliability. Peak will collaborate with TOPs to define the list of Elements based on historical performance of areas prone to congestion. Elements can also be created on the fly by RCSOs as needed based on RCSO Real-time Assessments and Operational Planning Analysis results. It is envisioned that the ECC will address implementation of the FERC-approved curtailment methodology including any resulting modifications to the current UFMP as part of Phase II. The expectation is that the webSAS tool would be retired upon completion of Phase II of the ECC project.

The primary tool for unscheduled flow mitigation in the Western Interconnection currently available to Peak Reliability Coordinator (RC) is WebSAS, which is used to calculate off-path scheduled tag curtailment responsibilities for Qualified Transfer Paths only. There are currently six Transmission Paths that have satisfied the qualification criteria described in the WECC Unscheduled Flow Mitigation Plan. Part of the reasoning for this qualification process is to use Qualified Controllable Devices to alter actual flows and minimize the impact of Unscheduled Flow on the power system prior to initiating schedule curtailments.

P a g e 4


The RC also currently uses real time contingency analysis (RTCA) to monitor situational awareness of the interconnection.

Recognizing the dynamic nature of interconnected system operations and adverse impacts that Unscheduled Flow may cause throughout the Bulk Electric System, the RC has identified the need for an expanded [?] Interconnection-wide congestion management tool with capability to monitor actual and forecasted flows on numerous Elements and determine contributing factors that can be mitigated to ensure the system remains within acceptable limits

Note: In this document an “Element” or “Monitored Element” is defined as including all items listed in the NERC definition of element in addition to the individual or grouping of facilities, lines, paths, or flowgates as monitored by the RC. In most circumstances, this document is referring to a flowgate or a path when the term “Element” is used, but nothing in this document should be interpreted to imply the broader use of the word “Element” is not also acceptable.

The ECC project will be broken into two phases. Phase I will provide the necessary functionality to improve Peak RC’s situational awareness including a three-hour look-ahead component. Phase I will allow the RC a deeper wide area view of the system and identify contributing factors to SOL or IROL exceedances.

Phase II will focus on the WECC Unscheduled Flow (USF) Reduction Guideline methodology for non-discriminatory curtailment of transmission service on Qualified Paths, approved by FERC on May 16, 2014, and replacement of webSAS functionality with the ECC. At the time of this writing, FERC has approved the WECC curtailment methodology. A significant WECC stakeholder process will be undertaken to best decide how to implement the new methodology in the ECC for phase II.

P a g e 5

BPA User, 02/06/14,

Peak RC currently relies on RTCA functionality to monitor situational awareness. That should be described here. Please address whether ECC replaces the RTCA? If not, how will RC use ECC and RTCA situational awareness tools going forward?

BPA User, 03/06/14,

It is unclear what additional stakeholder vetting is required for Phase II. The current USF Reduction Guideline methodology has already been vetted through the WECC stakeholder process, NERC, and FERC. Clarify if Peak RC intends Phase II to apply only to the current UFMP Qualified Paths or whether Phase II would include both Qualified Paths, plus other paths/elements that Peak defines. Address whether Peak intends to undertake changes to the current UFMP path qualification criteria, and vet changes through a stakeholder process.

Jeremy West, 06/06/14,

Xcel: In the Eastern Interconnection the issue of curtailment methodology is a business practice which NERC (the former IDC tool coordinator) has handed off to NAESB. Why should WECC retain any role in the establishment of business practices going forward? –sjb

BPA User, 03/06/14,

Clarify whether the purpose of this ECC Functional statement is limited to the scope of Phase I, Phase II or other? That is, is the purpose to develop WECC-wide situational awareness model capability (Phase I); and replace current UFMP WebSAS capability with ECC (Phase II)? Is the issue of the use (whether by Peak or others) of the ECC as a WECC-wide congestion management tool settled, or does it depend on Peak Reliability Board/MAC and Peak Member subscription contract concurrence?


1.1 Phase I versus Phase IIThe ECC project will be broken into two phases. Phase I covers all aspects of the ECC core functionality except for the curtailment component, which falls under phase II. Phase I is intended to establish the basic functionality of the ECC that will serve as the basis for phase II functionality. Accordingly, phase I will allow the RC to identify contributing factors to SOL exceedances, but will be used for situational awareness until phase II is completed. All inputs that will be necessary to support curtailments will be included in phase I; however, the curtailment functionality itself will fall under phase II. The curtailment functionality implemented in phase II will be consistent with FERC approved methodologies and will undergo a stakeholder vetting process.

1.2 What this Document DefinesThis document defines minimum functionality for the following Phase I objectives:

Enhance the RC awareness of real-time and look-ahead operating conditions:

o Calculate impacts on up to 1,000 Elements, including contingencies if necessary, as defined and modeled by the RC:

Real-Time occupies the current hour (h)

Look-ahead occupies the next three hours (i.e. h+1, h+2, and h+3)

o The impact calculation will account for real-time updates of the transmission system data to include existing transmission and generation outages from the West-wide System Model (WSM) via the State Estimator solution provided to the ECC once every five minutes

Calculation of shift factors every 15 minutes, or sooner, upon a manual execution.Additionally, every 15 minutes four new matrices of factors are created for each hour of the look-ahead time window.

Identify the sources of power flow, including tagged transactions and untagged transactions ,including but not limited to Balancing Authority (BA) Area Control Error (ACE) contributions to flow, reserve sharing qualifying events, and untagged Dynamic Transfers.

Interface with e-Tag systems for Interchange Transactions operations. The e-Tag systems’ interface will receive Interchange Transactions.information required by the ECC.

Interface with EIR webRegistry for entities’ definitions, source/sink points definitions, and POR/POD definitions.

1.3[1.2] What this Document Does Not DefineThis document does not define the following aspects of the ECC solution and instead, relies on the vendor to propose and define:

System design constructs including architectures, connectivity, back-up, fail-over, or redundancy needs.

Detailed definition of graphic user interface (GUI) view screens or displays.

P a g e 6


Xcel: Do we need a parallel effort to improve source/sink and POR/POD mapping in the region? – sjb

BPA User, 06/03/14,

The webRegistry is a list of approved points; there are no definitions or mappings. Mapping to the BA seems inadequate for managing flows because of the remote resources and sinks in WECC. Peak needs to determine specificity for how to maintain the mapping (like adding mapping to webRegistry so that it is available for all webRegistry users to assure consistency and no gaming). Mappings should be maintained for both the SE node-breaker and bus-branch models. Consider vetting mapping specificity in regional technical meetings.


Xcel: Assume this means that the information is an input into the ECC. –sjb


Xcel: How can we be confident that the modeled ACE contributions are a valid simulation? Also, why not assess reserve sharing qualifying events as a pre-contingent analysis package of impacts that would pertain in the event of a modeled contingency loss along with the reserve activation – otherwise in real-time the RSG delivery impacts would be unmanageable in terms of mitigating delivery impacts once the event has occurred. –sjb

BPA User, 06/03/14,

Will the specifications include methodology to determine “untagged” transactions? Consider vetting methodology through regional technical meetings.

BPA User, 06/02/14,

Will impacts be calculated in 15-minute blocks to match the scheduling increments


Xcel: Why pick 1000? – are we putting ourselves in a box? –sjb

BPA User, 06/02/14,

Is 1000 a daily or hourly limit? How often are elements updated, added or deleted? How are changes made in the look ahead and real time horizons?


Detailed definition of data inputs and outputs (I/O).

o Data I/O are classified at the object level but not at the Element level where attributes and metadata are generally defined.

Phase II detailed functionality as yet undefined due to the need for vetting the recently FERC approved curtailment methodology changes to mitigation procedures in the WECC stakeholder process.

P a g e 7


Xcel: Again – why WECC? Do we agree or want to include WECC in the role?

BPA User, 06/03/14,

Will Phase II address procedures and order of mitigation, actions including the coordinated operation of current UFMP Controllable Devices? The Stakeholder process is completed for the recently approved USF Reduction Guideline methodology. Expansion or replacement of the methodology approved under the revised UFMP would require additional Stakeholder process.


2 Inputs, Processes, Outputs and Mechanisms

The following section defines the functional requirements for the following:

1. Inputs – data objects that flow into the ECC and either consumed by operations/calculations to produce new data objects or as a pass-through for display/reporting.

2. Processes – dimension of the system which perform a function and/or calculation on the input data and models.

3. Outputs – data objects that flow out of the ECC for either display/reporting or downstream application/process inputs.

4. Mechanisms – Ancillary processing outside of the core ECC functionality, consisting of visualization of data, alarming, reporting, etc.

P a g e 8

class ECC ICOM View

«implementationClass»ECC

+ calculateModelFactors()+ calculatingMitigationActions ()+ dataRendering()+ displayFunctions()+ modelMapping()+ possibleFutureEventScenarios()

Inputs

+ Coordinated Outage System Data+ EIDE Database+ OATI Tagging System Data+ Registration Reference Data+ State Estimator Data+ WECC Interchange Tool Data+ West-wide System Model

Controls

+ Administration+ Policy+ Procedures+ Security+ Workflow

Outputs

+ GLDF+ GSF+ LSF+ OTDF+ PTDF+ TDF- Visualization of Operational Results+ ZSF

Mechanisms

+ Alarming+ API+ GUI+ Import / Export+ Reporting

«trace»

«trace»

«flow»«flow»

Figure 1 – Illustration of ECC ICOM Model


2.1 Data FlowThe graphic below represents the data flow and components of the phase I ECC. Several key inputs, processes, and outputs are designated and further described by the numbers below.

2.2 InputsInputs are data objects required by the ECC for performing operations, calculations, reporting, or display. For the purpose of this specification, each of the following data elements is classified by Data Group, Data Class Name, Description, and Source Name; these represent the anticipated data inputs for ECC.

Detailed definitions are expected to be provided by the vendor within a system design specification or similar artifact and shall include the following detail:

ECC Use – name of calculation or operation consuming the input data.

Attributes – data Element details (e.g. PSBank, Name, TapPosition, LastChange, QualityCode).

Format – expected format of the data object (e.g. CSV, XML, Other).

Frequency – expected temporal frequency of the data object (i.e. every 5 minutes).

Trigger – what triggers the data to be an input to ECC.

Accuracy/Precision – any adjustments to the accuracy or precision from the source data.

Integration – specified integration methods for retrieving data (e.g. Web Services, Pub/Sub, ICCP).

The ECC will be tightly integrated with the real-time hour (h) data and forecast data for the next three hours (i.e. h+1, h+2, and h+3). To accurately determine the impacts on and contributions to power flows on monitored Elements, the ECC shall use the following inputs.

P a g e 9


Source of Record

Data Type Description

Coordinated Outage System (COS)

Generator Scheduled Outage Information

Forecasted and actual generator outages and derates > 50 MW.

Coordinated Outage System (COS)

Transmission Scheduled Outage Information

Forecasted transmission outages > 100 kV.

EIDE Database Generator Unit or Generating Station Commitment forecast

Real-time and forecasted generator MW output, service load, and pump storage or aggregation of these values for a generating station.

EIDE Database Load Forecast Data Forecasted load for each BA area.

NAESB EIR Registry or WECC Registry

Mapping of Source/Sink to BA and POR/POD to BAdata

Mapping will require a manual process by the BAs.

OATI Tagging System

E-Tag Data E-Tag source/sink and/or POR/POD data, mappings to generators and loads in the model.MW profile, transmission priority, and other relevant data for tagged transactions

OATI Tagging System

Net Scheduled Interchange (hourly)

Forecasted hourly net scheduled interchange.

OATI Tagging System

Next-Hour Dynamic Transfers

Forecasted intra-hour coordinated transfer of energy between BAs.

Registration Reference Data

JOU Allocations Fixed percentage provided by Peak RC to determine allocation.

State Estimator Actual Transmission Facility Flows

Actual Transmission flows are available through the SE solution interface.

SCADA ACE Values Real-time telemetered ACE values from Balancing Authorities

SCADA Dynamic Transfer Telemetry

Real-time telemetered data for Dynamic Schedules and Pseudo-Ties reflecting the real-time value of the MW energy flow.

State Estimator DC Line Flow MW flow over DC lines as an SE output.

State Estimator Facility Ratings Facility Ratings can be updated on the fly so they need to be retrieved from the SE solution instead of the base model WSM.

P a g e 1 0

BPA User, 02/06/14,

How will 15 minute schedule interval adjustments be captured?

BPA User, 03/06/14,

Mapping is separate from e-tag data. Who will be responsible for ensuring E-tag source/sink data track the ECC source/sink POR/POD mapping? How will 15 minute schedule interval adjustments be captured in forecasts? Consider regional technical meetings to address mapping.

BPA User, 02/06/14,

BA-level mapping seems inadequate for managing flows. Mapping needs to be defined at a much more granular level.

BPA User, 02/06/14,

What controls for consistency, and avoiding gaming?

BPA User, 03/06/14,

BA-level mapping seems inadequate for managing flows. Mapping needs to be defined at a much more granular level. Consider regional technical meetings for mapping specificity.

BPA User, 02/06/14,

What frequency/granularity?

BPA User, 02/06/14,

2.2.7 explains that forecast may be provided as aggregate plants/projects if individual unit granularity does not exist. Clarify further that RC will request data from GO/GOP/LSEs in accordance with IROL-010-1a, R3, and not limit requests to BA/TOPs.


Source of Record

Data Type Description

State Estimator Path and Flowgate Limits

Interface limits are available through the SE solution interface.

State Estimator Real-Time Pump Storage

Actual pump MW is available in the SE solution interface.

State Estimator Real-Time Unit or Generating Station actual MW Output

Actual unit or generating station MW Output is available in the SE solution interface.

State Estimator Phase Shifter and LTC Data – Real-Time Tap Position

Actual phase shifter and LTC tap is available in the SE solution interface.

State Estimator Topology - Actual Transmission Outages

Actual values are obtained by the State Estimator.

State Estimator Topology - Circuit Breaker and Switch Statuses

List of status of all circuit breakers and switches.

State Estimator IROLs (the limit value)

IROLs are dynamic and are provided in the SE solution interface.

State Estimator Topology Actual values are obtained by the State Estimator.

State Estimator SOLs (the limit value) SOLs are dynamic and are provided in the SE solution interface.

State Estimator Generator AGC Response to Generator Outages

State Estimator provides a list of generators that will respond (steady-state but not real-time) to generator outages.

WECC Interchange Tool

Net Scheduled Interchange (hourly)

Forecasted hourly net scheduled interchange.


Next-Hour Dynamic Transfers

Forecasted intra-hour coordinated transfer of energy between BAs.


Real-Time Dynamic Transfers

Real-Time intra-hour coordinated transfer of energy between BAs.

West-wide System Model

Registered Generator CapabilitySystem Topology

Generator Pmax and Pmin available through the WSM.Modeled system topology for the Western Inteconnection.

P a g e 1 1


Xcel: I don’t see ACE data inputs listed above, where is that coming? What method will be used to assign ACE contributions to the flow impact calculation? (for example positive ACE to nearest negative ACE or all positive ACE pro-rata to all negative ACE?

BPA User, 02/06/14,

How will 15 minute schedule interval adjustments be captured?


2.2.1 West-Wide System Model (WSM)Peak will provide a network model every four weeks that is used as the base model for all ECC calculations. The WSM base model will be provided in CSV format (or other as defined through system design.) The WSM base model will include typical modeling attributes including, but not limited to:

Topology, including equipment connectivity

Line and transformer impedances

Generator maximum and minimum outputs

Transformer and phase shifter tap ranges

2.2.2 SE (State Estimator) Savecase DataPeak runs a state estimator using the WSM with over 125,000 measurements mapped to the network model. The ECC will read a new set of state estimator case data provided by Peak once every five minutes. The state estimator data provided to the ECC will either be a subset of “deltas” or states ofn the system that are to be applied to the WSM base model, or it will be an entire case with all relevant state estimated data and system topology. The actual State Estimator data set will be provided to OATI every five minutes to the ECC in a prescribed format that will be determined as part of the detailed design process performed by the vendor.

Real-time data provided to the ECC from the Peak state estimator every five minutes includes:

Actual circuit breaker and switch status

Generator and pump output (MW)

Individual load (MW)

Phase shifter tap position

LTC tap position

DC line flows

Transmission line and transformer MW flow

Interface MW flow

Transmission line and transformer limits

Interface MW limit

2.2.3 ECC ModelThe ECC will receive the base WSM monthly, or upon update by Peak Reliability. The base WSM model will be updated every five minutes to reflect state estimator calculated system conditions. The ECC starting conditions are the WSM base model with all necessary five minute state estimated data applied. The ECC starting conditions are used as a primary input into the various shift factor calculations, including subsequent calculations for data such as weighted shift factors.

P a g e 1 2


Xcel: Why?

BPA User, 02/06/14,

Interface or monitored Elements?


Xcel: Why?


Xcel: Why relevant to distribution factors calculation?


Xcel: Does this have a material impact on the distribution factors?


Xcel: Good! - yea


Xcel: Why is this needed by ECC?


Xcel: Why is this relevant to the ECC, except perhaps to confirm availability status?

BPA User, 04/06/14,

What BA/TOP stakeholder briefing will be available to address SE/RTCA interface with ECC and obtain input? Recommend using regional BA/TOP stakeholder process to work through tool access, data/results sharing, and roles and responsibilities.


Xcel: most of the data proposed to be sent to the ECC looks like it is not material to the calculation of distribution factors / shift factors. Why is this extra data being provided? Wont handling all that data increase the project costs?]


Xcel: Not sure if this is addressed elsewhere, but what is the plan to address the modeled tap setting when the ECC calculates distribution factors? –sjb


2.2.4 ECC Element DefinitionsThe ECC will have the capability to model any Element of the WSM for monitoring WECC-wide situational awareness and Element SOL exceedances. An Element may be modeled with or without a contingency and may represent for example, a WECC Path, a group of transmission lines, a single facility such as a transmission line or a transformer, or a facility accounting for the loss of another facility. The individual facilities that make up an Element must exist in the WSM to be defined for use in the ECC. Upon Phase II implementation, constrained Elements can be mitigated by initiating congestion management procedures including issuance of curtailments. The process around managing Elements in the ECC is defined in a later section of this functional specification.

2.2.5[2.2.4] Mapping WSM to ECCA critical component of ECC functionality includes the various layers of mapping that need to occur to the WSM. These mappings link defined BA/TOP points (Source/Sink/POR/POD) in the EIR Registry to the WSM. The ECC will use the EIR Registry to obtain POR/POD to TSP mappings and Source/Sink to BA mappings. Additional mapping groups, such as Generator Unit/ Generating Station to BA or TSP/POR/POD to BA, will be accommodated within the ECC itself as such needs are scoped with the vendor during detailed design. A critical mapping within ECC is to link equipment from the WSM to relevant Source/Sink/POR/POD points. The ECC will have flexibility to support varying levels of granularity; for example, these mappings can be very broad to link equipment to an entire BA definition or very specific to link an individual generating unit to a source name. The display to create this cross-linked mapping will be built in the ECC and maintained by Peak RC staff. A Peak business process will be created to collaborate with stakeholders for initial mapping efforts as well as continued maintenance as mappings require changes.

2.2.6 Real-Time DataPeak will provide real-time data, primarily from Peak’s SCADA application, to the ECC where the data is not available in the state estimator solution.

Dynamic Transfers are the primary data type that must be provided to the ECC directly from Peak’s SCADA. The ECC will handle monitor Dynamic Transfers to give maximum situational awareness of Dynamic Transfer their impacts on ECC Eelements. Specific requirements for Dynamic Transfers include the following:

The ECC will rely upon estimated Dynamic Transfer information from eTags to forecast anticipated use in future three hours.

The ECC will utilize real-time telemetry on Dynamic Transfers that is provided to the ECC via the State EstimatorSCADA data in order to monitor current hour impacts or other available telemetered sources.

The ECC will utilize and combine all Dynamic Transfers by each distinct Source/Sink/POR/POD combination .

P a g e 1 3

BPA User, 04/06/14,

Will specs impose consistency for telemetered DT data? Will intermediate BAs have access to data? Refer to BA/TOP stakeholder process.

BPA User, 03/06/14,

Dynamic transfers are submitted as e-tags (dynamic schedules or pseudo ties). Should e-tags be added as an input for real time data in this section or should Dynamic Transfer discussion be moved under 2.2.6 Scheduled flow e-tags section?

BPA User, 06/02/14,

1.1 provides that up to 1,000 Elements will be monitored. Is 1000 a daily or hourly limit? How often are elements to be updated, added or deleted? How are changes made in the look ahead and real time horizons?


Actual flows (from telemetered sources) for Dynamic Transfers will be provided to ECC aggregated mapped toby each distinct Source/Sink/POR/POD combination or as discrete a mapping as can be accommodated (i.e. generating stations for wind farms).

For prioritization of curtailing Dynamic Transfers tags, the ECC will specify need transmission priorities from associated e-Tags in the WECC Interchange Tool or other non e-Tag sources [??] and will be used by the ECC to identify curtailment priority that can be determined during detailed design with the vendor in Phase II?.

For curtailment purposes the ECC will utilize Transmission Allocation information from Dynamic Transfer eTags to determine the maximum amount of dynamic transfer that may occur at any given moment and energy profile information to determine actual Dynamic Transfer visualization and contribution to power flows on a particular element?.

Unscheduled flow can have major impact to the transmission system. The ECC should be aware of current operating hour unscheduled flow and shall make that information available through visualization of the flows on a particular Element. The specific real-time inputs for identifying unscheduled flow in the ECC include:

ACE – near real-time ACE values from SCADA will be made available to the ECC at least once every five minutes. The ACE impacts on the defined ECC Eelements are updated upon receipt of a new ACE value. The process for passing along the near real-time ACE values are to be determined in the detailed design phase of the projectutilizing ACE in the ECC includes determining whether a BA is providing power to the Interconnection via a positive ACE or receiving power from the Interconnection via a negative ACE and then applying the ACE impacts across all defined Elements within the ECC. The design process with OATI will determine the exact methodology by which ACE impacts are computed per Element.

RSG – Reserve Sharing Group activations are to be made available to the ECC upon activation of an RSG event. RSG information necessary for calculating impacts will be provided to the ECC, such as:

o The resource(s) lost during the RSG event.

o Generators that are responding expected to respond to athe RSG event.

o Generator MW output change due to the RSG event.

The design process with OATI will determine the exact methodology by which RSG impacts are computed per Element.

Native Load/Network Integration Load Serving – Native load/Network Integration Load served within a Balancing Authority is derived by the ECC through the use of other inputs to the ECC and will be calculated based on deductions from those inputs such as the tagged flows, actual load, actual generation, losses, reserves etc. This value is not explicitly provided to the ECC from an external source.

[2.2.5] ECC Element DefinitionsThe ECC will have the capability to model any element of the WSM for use in congestion managementmonitoring WECC-wide situational awareness and Element SOL exceedances. An element

P a g e 1 4

BPA User, 06/04/14,

Is Congestion Management Phase I or is Phase I modelling only? Phase II contemplates replacing webSAS for USF management. Under Phase II, will congestion management be limited to USF curtailments on Qualified Paths under the current UFMP, or expanded; or will interconnection-wide congestion management be part of Phase III development. What Peak Board/MAC direction and Peak Member subscription contracts are needed for RC to pursue Western Interconnection wide congestion management tool? Please also address or clarify RC v. BA/TOP roles in implementing congestion management based on ECC situational awareness result (i.e., does ECC identify relief needed and BA/TOP determine curtailment/redispatch action), process for resolving conflicts between congestion management tools used by BA/TOPs and RC ECC, etc. Also distinguish how proposed Peak RC role under ECC v. TOP/TSP roles are expanded for congestion management from roles identified in 142 FERC ¶61,084 (i.e., RC approve/deny BA/TOP request for curtailment; BA/TOP approves curtailment request or implements alternative actions to meet relief requirements). These issues should be discussed in regioinal BA/TOP stakeholder process.

BPA User, 06/02/14,

1.1 provides that up to 1,000 Elements will be monitored. Is 1000 a daily or hourly limit? How often are elements to be updated, added or deleted? How are changes made in the look ahead and real time horizons?


Xcel: So ECC will derive the internal BA NLS through subtraction. This is OK for phase 1, possibly, but led to the complaint that prompted the parallel flow visualization tool in the East, because there are some non-tagged internal BA schedules that are not tagged and do not have firm service priority

BPA User, 06/04/14,

Clarify whether assumption is that NLS and intra BA Network Integration Load is tagged or untagged? Stakeholders will want to understand the methodology for calculating unscheduled flows to NLS/Network Integration Load. Consider holding regional technical meetings on the methodology


Rocky Mountain RSG uses manual Excel sheet and just call generators to move units


Xcel: As mentioned above, waiting until the activation occurs in order to derive this information is too late for impact evaluation. Why is this even necessary in the ECC? Wouldn’t this be more appropriate, useful and simpler simply to include in the RC’s state estimator-based security analysis application?

BPA User, 06/02/14,

This detailed design phase hasn’t been described yet. Is that part of Phase I, Phase II or is this a new Phase?


Afraid that this is functionality OATI was pushing to drive up the price and not really needed


Xcel: Personally I consider this a Cadillac when a Volkswagen would do. But if we proceed with this element, we also need to know information on the ECC method to determine source/sink mapping for the long and short BA ACE values, because the source/sink mapping used could have a material result on the impact. Also what transmission service curtailment priority should be assumed for ACE delivery impacts? –sjb


Xcel – using the term unscheduled flow, given its history in the WECC practices, carries baggage. Is it possible to devise a new name for this category of flow impact assessments? –sjb

BPA User, 06/04/14,

Distinguish what will be done in Phase I from Phase II for USF modelling. Clarify whether Phase II is limited to replacing webSAS with ECC, or whether it also involves USF congestion management using the ECC tool, including whether the current UFMP procedures, roles and responsibilities will be followed?

BPA User, 04/06/14,

Clarify whether curtailment is a Phase I, Phase II or other phase scope issue? Clarify how Dynamic Transfer flows will be tracked in the ECC situational awareness tool capability? If congestion management is a Phase II issue, is discussion here out of scope?

BPA User, 02/06/14,

In a curtailment, the amount of flow reduction available is based on the actual flow, not the Transmission Allocation on the DT tag. Curtailing a tag to zero that had a TA of 100 and an actual flow of 50 will only be worth 50 MW of reduction and curtailing that same tag by 50% down to 50 MW will yield no relief. Note that WebSAS does not currently correctly deal with Dynamic Transfers transmission, market, or energy profiles and reliability limits. How will ECC deal with impacts from intra-BA and inter-BA dynamic transfers?


may be a WECC Path, a transmission line, a group of transmission lines, or a transformer. The individual facilities that make up an element must exist in the WSM to be defined for use in the ECC. The process around managing elements in the ECC is defined in a later section of this functional specification.

[2.2.6] Scheduled Flow (e-Tags)The ECC will read e-Tags for impacts in the current operating hour, as well as for the future look-ahead hours 1-3. The e-Tags will provide the details about all tagged uses of the system and will be used as a primary input into the impact calculations. The mappings process described in the section above will map e-Tags to the most granular level available.

Dynamic Schedules by definition require an e-Tag, and the following requirements detail how they will be used:

The ECC will rely upon estimated Dynamic Schedule information from e-Tags to forecast anticipated use in the look-ahead three hours.

The ECC will utilize and map Dynamic Schedule e-Tags by each distinct Source/Sink/POR/POD combination or as discrete a mapping as can be accommodated (i.e. generating stations for wind farms).

On Dynamic Schedules, energy profile information from the e-Tag will be used to estimate the impacts on monitored Elements for the look-ahead hours. Timely updates to the energy profile on Dynamic Schedule e-Tags will aid in the ECC’s look-ahead hour impact accuracy.

Transmission priority from Dynamic Schedule e-Tags will be available for usage by the ECC. In Phase II, this same information will be utilized in establishing priorities for issuing curtailments.

The information required on Dynamic Schedules is also required on Pseudo-Ties. Based on the revised INT-004 standard that has been approved by NERC and is pending FERC approval, Pseudo-Ties must either submit an e-Tag or submit similar information to congestion management tools. Peak sees the use of e-Tags to collect this information on Pseudo-Ties as the established method, but the ECC also should be designed with a set of inputs that mirror e-Tags in collecting the following information on Pseudo-Ties:

Source/Sink/POR/POD combination MW Energy Profile Transmission Priorities for the Pseudo-Tie path

2.2.7 Look-Ahead Data Inputs The ECC shall utilize the following data inputs associated with the look-ahead functionality for the next three hours (i.e. h+1, h+2, and h+3).

COS Outages and Returns to service - Planned transmission and generation outages for hours one, two and three will be provided in CSV, or other format as defined through system design, as an input to the ECC. Transmission and generation facilities that are returning to service within the next four hours are also provided to the ECC.

Load Forecast -– BA area load forecast for hours one, two and three will be provided to the ECC. The load forecast data will be provided as an error corrected forecast to the ECC. The ECC will

P a g e 1 5

BPA User, 02/06/14,

What granularity of load forecasts – entire BA forecast, or other?


Xcel: Assume this is only needed to perform the subtraction that imputes the NLS schedule, i.e. that assesses the flow impact of non-tagged deliveries?

BPA User, 06/03/14,

Schedule adjustments are very dynamic between Preschedule (9AM on the WECC pre schedule day) and the delivery hour or interval, and will likely be more so with 15 minute scheduling. Consider using regional technical meetings to develop predictive model capabilities.

BPA User, 06/03/14,

Should Dynamic transfer information be moved to this section?


not perform any smoothing or correcting of the load forecast values. The ECC will be able to support and utilize load area forecasts on a more granular level.

Generation Forecast - Forecasted generation output for hours one, two and three will be provided to the ECC. The generation forecast is provided at the most granular level available. The preference is to obtain forecasts for every generating unit that is defined within the WSM, but. tThe forecast may be provided as an aggregate plant levelgenerating station forecast if the individual unit granularity does not exist. The ECC will not have to doperform any smoothing or correcting of the generation forecast values, as this function will be performed outside the ECC.

NSI Forecast – Net area Scheduled Iinterchange per area is to be provided as an input to the ECC from the Western Interchange Tool (WITOATI tagging systems). The NSI will be composed of the most recent set of approved e-Tags prior to NSI being sent, so any e-Tags past the data retrieval would not be obtained until the next sample. An external application will pull the data from WIT and perform data validation and correction to ensure accuracy and usability of the data. The NSI data will then be provided back to the ECC for use as an input to various ECC calculations. The ECC will not have to doperform any smoothing or correcting of the NSI values, as this function will be performed outside the ECC.

2.3 ECC Element and Calculations ProcessesProcesses within the ECC are mechanisms used to transfer datamanage Elements, perform calculations, and other automated or manual actions.

2.3.1 Element Management ProcessThe Eelements of the ECC are the core facilities, or collection of facilities, that are defined for monitoring in the ECC. There are many processes that are defined to capture the proper definition, and management of the Eelements within the ECC. Peak will collaborate with TOPs to define the list of Elements based on historical performance of areas prone to congestion. Elements can also be created on the fly by RCSOs as needed based on RCSO Real-time Assessments and Operational Planning Analysis results. Peak will then need an ongoing business process to maintain Elements after initial setup.

Use Cases define user interactions at a functional level. It is not the intention of this document to necessarily define how the use case or workflow is to be implemented. For this document, the use cases and workflows themselves are defined with minimum functionality expected to be met by the tool.

The following use cases shall be implemented in the ECC:

1. Create an Element

2. Modify an Element

3. Deactivate an Element

4. Delete an Element

[5.] Auditing the Creation of an Element

P a g e 1 6

BPA User, 06/03/14,

Will RC work with TOPs on processes for identifying Elements, additions, modifications and removals? If not, how will notice of monitored elements be communicated to TOPs? How frequently can Elements be created, modified, deactivated, deleted? How will defined Elements accommodate the Qualified Paths and Controllable Devices under the current UFMP? Address as part of BA/TOP stakeholder process.


Xcel; Shouldn’t this tie-out exactly with the eTag data

BPA User, 03/06/14,

Plant/project level forecasts are likely to be more available than unit commitment detail. If unit commitment detail is required, does RC intend to obtain this data from GO/GOPs?


Xcel: Same comment as above on load forecast


2.3.1.1 Creating an ElementThis use case represents an authorized user’s ability to create an Element. Minimum functionality to support this use case shall include:

The RC role is the only role authorized to create an Element.

Elements shall be selected based on the WSM modeled equipment.

Elements must exist in the WSM.

The information entered during creation of an Element shall be recorded in an audit log including all entry fields as well as the user information.

2.3.1.2 Modify an ElementThis use case represents an authorized user’s ability to modify an Element. Minimum functionality to support this use case shall include:

The RC role is the only role authorized to modify an Element.

The information entered during modification of an Element shall be recorded in an audit log including all entry fields as well as the user information.

For the purpose of this document, reactivating an Element from a deactivated state shall constitute a modification.

2.3.1.3 Deactivate an ElementThis use case represents an authorized user’s ability to deactivate an Element. Minimum functionality to support this use case shall include:

The RC role is the only role authorized to deactivate an Element.

For the purpose of this document, deactivation shall mean ‘soft-deletion’ (i.e. remove the Element from the ECC’s operational functionality).

Deactivation will notify the creator of the Element through an auditable mechanism that the Element has been deactivated.

The information entered during deactivation of an Element shall be recorded in an audit log including all entry fields as well as the user information.

An Element will be marked as deactivated and will not be hard-deleted or permanently deleted from the system.

2.3.1.4 Delete an ElementThis use case defines functional rules for deleting an Element. The ECC shall prohibit a unilateral deletion function of any Element in order to allow thorough traceability via the audit use case. Deletion of an Element is to be restrictive and subject to formal authorization. The following functional requirements support this construct:

Under normal operation, an Element shall be marked as deactivated and will not be hard-deleted or permanently deleted.

P a g e 1 7


The vendor shall supply an appropriate administrative hard-deletion or permanent-deletion mechanism for the administrative role while ensuring appropriate system and database integrity.

An Element may be deleted only via administration-level credentials.

An Element may only be deleted with approval from Peak RC

Vendor shall archive any historical ECC action (e.g. alarms, curtailment action, modification, etc.) on the deleted Element.

2.3.1.5 Approving an ElementThis use case represents an authorized user’s ability to approve a newly created Element, modified Element, or deactivated Element. Functionality requires the ECC to enforce a workflow whereby an authorized user performing the aforementioned activities shall only be committed upon successful approval by a user authorized to perform the approval. Minimum functionality to support this use case shall include:

For the purpose of this document, approval shall mean both technical and business process:

o Technical approval: the ECC shall perform basic validation on user-entry data fields to the extent of ECC operational logic.

o Business process approval: RC is responsible for developing business practices associated with the approval use case.

The RC or designated entity shall approve the created/modified/deactivated Element.

The approval screen shall at least have the following fields:

o Date/Time fields associated with create/modify/deactivate actions

o RC User ID for create/modify/deactivate actions

o Data fields for create/modify/deactivate actions

o RC User ID for approve actions

o Comments captured during RC create/modify/deactivate actions

o Effective date/time of the Element once RC approvescreate/modify/deactivate action

The RC approval process of an Element shall be recorded for audit purposes.

The RC create/modify/deactivate process will trigger notification to the TOP assigned to the Element which was changed.

[2.3.1.6] Auditing the Creation of an ElementThis use case represents an authorized user’s ability to audit data and actions associated with the creation of an Element. Functionality may include ad hoc querying or reporting. Minimum functionality to support this use case shall include:

Audit user actions and data entry for created Eelements.

Audit approver actions and data entry for created Eelements.

P a g e 1 8


Xcel: suggest that all modifications should be auditable

BPA User, 06/02/14,

Does this allow for BA/TOP comments?

BPA User, 06/02/14,

Does this conflict with prior statements that the RC role is the only role authorized to create/modify/deactivate elements?


Audit historical alarms and modifications associated with an Element over a user-entered timespan.

Include all date and time stamps for actions or entries.

Include all users ID’s associated with actions or entries.

Via appropriate display(s), audited data fields shall show original state and changed state where applicable.

2.3.2 Calculate Shift FactorsShift factors are the most basic calculation performed within the ECC. There are a variety of shift factors calculated, some describing the impact on Eelements from a single generator, others describing the impact on Eelements from a group of generating resources.

Shift factors will be calculated every 15 minutes for a rolling window from T0 through hour ending T0+3.

Shift factors will be calculated for 15 minute intervals for the current operating hour, followed by hourly intervals for hours T1 – T3.

A near real-time state estimator solution case is provided to the ECC every 5 minutes, yet the shift factors are only calculated every 15 minutes. The primary use for the state estimator solution when no shift factor updates are occurring is in the impact calculation process.

The ECC shall calculate the following types of shift factors:

2.3.2.1 Power Transfer and Outage Transfer Distribution Factors Power Transfer Distribution Factor (PTDF) Elements are Eelements that do not consider

contingencies during curtailment evaluation. With PTDF Elements the monitored branches alone are considered during curtailment evaluation.

Outage Transfer Distribution Factor (OTDF) Elements are Elements that take into account a predefined contingency during curtailment evaluation. With OTDF Elements the monitored branches are considered with a specific facility removed from service during curtailment evaluation.

An Element can exist as a PTDF Element or an OTDF Element.

An Element defaults to a PTDF Element unless OTDF branch data is specified in the Element creation process.

2.3.2.2 Generation Shift Factors A Generation Shift Factor (GSF) represents the change in flow on an Element due to an

incremental injection at a generator bus and a corresponding withdrawal at the swing bus.

between any two generators is the difference between the generators’ GSF to the swing bus.

The principles of superposition shall apply when calculating GSFs, so the GSF difference between two generators is the difference between the computed GSFs for each generator to the swing bus.

P a g e 1 9


Xcel: A Generation Shift Factor (GSF) is the flow impact on an Element between a generator and the swing bus. [There is no reason to be calculating G-G shift factors in my opinion, so I proposed this revision to be consistent with my understanding. Am I missing something here? I thought the PTDF and OTDFs were derived through combination (linear superposition) of the GSF and LSF impacts with respect to the swing bus. The UFMP makes no provision for G-G distribtioin factor impact calculation, as I understand it anyway, so not sure why we would want to preserve the original language.]

BPA User, 06/02/14,

This description is not correct, GSF is not the difference between any two generators. Per NERC: The Generation Shift Factors (GSF) represent the change in flow on a flowgate due to an incremental injection at a generator bus, and a corresponding withdrawal at the swing bus. This definition is in the same presentation that contains the rest of the bullets.


BC Hydro: A near real-time state estimator solution case will be provided to the ECC every 5 minutes whereas the shift factors will be calculated every 15 minutes or sooner upon manual execution. The vendor has resolved performance impediments of its tools within the industry previously through various approaches. Assuming performance is not significantly hindered by increasing the frequency of shift factor calculations, what is the rationale for calculating shift factors every 15 minutes? Is there increased value in calculating shift factors every 5 minutes to align with the updated state estimator case? If yes, what is that value? If no, why not?


Xcel: May mention to ask for a logic check in factor calculations to avoid problem where RC asks for a distribution factor calculation on an element that is out of service (I think this caused a hang-up in the IDC once).


GSFs are used in Transmission Distribution Factor (TDF) calculations and Generation-to-Load Distribution Factor (GLDF) calculations.

GSFs on the Element GSF display in the ECC shall indicate which generators contribute to or relieve congestion on a selected Element.

Example: If a generator indicates a GSF of 15.2% on Element X, this means that 15.2% of the generator’s output flows on Element X provided the injection is withdrawn at the swing bus.

2.3.2.3 Transmission Distribution Factors A Transmission Distribution Factor (TDF) represents the impact of an Interchange Transaction

on a given Element and determines which are eligible for curtailment in the ECC.

o Only those Interchange Transactions with a TDF of n% or greater, as determined by RC approved standard/practice/policy, are subject to Curtailments.monitoring for impacts on Elements.

o Example: If a tag’s calculated indicates a TDF indicates an impact of 8.3% on Element X, this means that 8.3% of the transfer amount on that tag flows on Element X.

TDFs address the question, “What portion of a power transfer shows up on Element X?”

ECC calculations shall use the most granular Source, Sink, Point of Receipt (POR), and/or Point of Delivery (POD) for determination of TDFs.

ECC shall integrate with the NAESB EIR Registry or WECC Registry and obtain the most current POR/POD/Source/Sink information for TDF calculations. This will require some manual mapping on the model data to establish the needed granularity:

Source/Sink to BA

POR/POD to BA

ECC shall calculate the real-time TDFs on monitored Eelements based upon the model incorporated into the tool and the points mapped to the model.

ECC must use real-time system topology and data, including actual generation and outages, when calculating TDFs and mitigation responsibilities.

ECC must be able to create a matrix to show all POR/POD combinations in order to accurately model and determine TDF of monitored elements:

o Mapping of Source/Generators to POR/POD.

o Mapping Source/Generator to a Regional Zone/sub- zone/BA (or by company/area as per State Estimator).

TDFs shall be calculated as the weighted sum of the GSFs of the generators that comprise the BA, Zone or sub-zone, or any aggregate of generators, where the weighting factors are pre-determined based on individual generator’s capacity (or some other criteria as to be decided) or determined in real-time, based on individual generator outputs. TDFs are calculated as follows:

TDFBA=[∑ (GSFGenerator (BA )∗W Generator (BA ))] /∑W Generator (BA)

Where:P a g e 2 0

BPA User, 06/02/14,

Use actual output for at least the current hour and then forecasts beyond that


Xcel: ??? Am I missing something here? With the full system topology, wouldn’t there be generators, load zones and then POR/POD at the border delivery points between transmission providers. The only reason to retain the POR/POD-level data is to recognize that different transmission providers may be providing different levels of transmission service curtailment priority to the delivery path. Right?

BPA User, 06/02/14,

Not sure why this is needed? The ECC is only going to use forecasts and actuals from all of the generators or the loads. How will the volume of multiple competing and conflicting paths/TDFs be managed?


Xcel: What about a future hour when an Element status may be changed? –sjb

BPA User, 06/02/14,

Basing TDFs on BA to BA source/sinks or POR/PODs seems inadequate for congestion management because of the extent of remote generation and loads in the WECC. What effect for Pseudo tie dynamic transfers between remote resources and loads within a single BA?


BC Hydro: The WECC Registry reference can be removed since it has been incorporated into the NAESB EIR.


Xcel: Not clear- why would the TDF be shown on an eTag? Or does this example mean “if the ECC calculates a TDF for a given eTAG of 8.3%”?


Xcel: I thought in the UFMP filing, this percentage was 10%. My advice is don’t settle for anything lower than 3% or everyone’s head will explode from the massive number of inconsequential curtailments that would result. Most cases in the East use 5%, as I understand it.

BPA User, 06/04/14,

Clarify whether ECC will use 10% impact, as included in the approved USF Guideline. BPA also uses 10% in its curtailment calculator. How will impact factors be evaluated?


TDFBA is the TDF of a Balancing Authority

GSFGenerator(BA) is the GSF of a generator in a Balancing Authority

WGenerator(BA) is the weighting factor of a generator in a Balancing Authority

2.3.2.4 Load Shift Factors Load Shift factors (LSF) are used to calculate GLDFs, which are used to determine Generation-

to-Load (GTL) obligations (i.e. the LSF is a component of the GLDF.

LSFs shall be shown along with GSFs on the GLDF displays in the ECC.

Similar to TDFs, LSFs are calculated as the weighted sum of individual loads distribution factor, for all loads belonging to a BA or zone.

The ECC will have the ability to model LSFs at the BA level or at a more granular level. Initially, Peak plans to model at the BA level to match the mapping from the WSM.

[2.3.2.5] Generation-to-Load Distribution FactorsThe Generation-to-Load (GTL) process allows for non-firm and firm of Network Integration (NI) and Native Load (NL) services to be treated comparably with non-firm and firm Point-to-Point (PTP) Transactions during transmission service evaluations. The ECC assists the RC in allocating appropriate relief of all PTP transactions and GTL impacts in order to ensure comparable curtailment.

A Generation-to-Load Distribution Factor (GLDF) is the difference between a GSF and an LSF and determines the total impact of a generator serving its native BA load on an identified transmission facility or monitored Element.

GLDFs shall be used to determine the GTL of BAs where generators in the BA serve the native and network integration load of the BA.

The ECC should allow portions of Native Load to be served by an e-Tag while properly decrementing the remaining load to be represented as untagged Native / Network Integration load

The GTL calculation shall form the basis for determining a BA relief obligation when curtailment is needed.

Only those generators with a GLDF of n% or greater, as determined by the RC approved standard/practice/policy, are used in calculating monitoring the GTL relief obligationElement impacts for situational awareness.

GLDFs shall be shown in the Element GLDF display and the CA GLDF display in the ECC.

o In the Element GLDF display the user selects an Element and is shown a list of generators that contribute to flow as a byproduct of serving their own BA area load (i.e., the GTL impact).

o In the CA GLDF display, the user shall be shown a listing of Elements that are impacted by generators serving their own BA area load. From this list, the user can drill down and view the generator contribution to flow.

P a g e 2 1


Xcel: Recommend a number consistent with the % above, prefer 5% to be relatively standard, but higher is OK.

BPA User, 06/04/14,

The GTL should be based on the net load after accounting for other service to that load (for example, import schedules and customer generation). BAs should be able to define the components that go into the GTL process (for example, the granularity of the generator and service point groupings). Address in BA/TOP stakeholder discussions.


Xcel: Assume that multiple LSEs in a BA will each have their own zone. We should not preserve the old UFMP aggregated zones used today. –sjb

BPA User, 06/04/14,

The GTL should be based on the net load after accounting for other service to that load (for example, import schedules and customer generation). BAs should be able to define the components that go into the GTL process (for example, the granularity of the generator and service point groupings). Address in BA/TOP stakeholder discussions.


Xcel: Would be curious to determine the rules/algorithm used to establish a generator weighting factor - who gets to pick, the merchant, TP or RC? Assume nukes and VERS are zero weighting factors?]


2.3.2.5[2.3.2.6] BA/Zonal Shift Factors BA/Zonal Shift Factors (ZSF) represents the shift factors of a subset of generators of a BA or a

Load Zone that is a subset of a BA area.

ZSFs are calculated in the same manner as TDFs and support increased levels of granularity for factor calculations.

Peak will collaborate with entities to utilize the ZSFs appropriately..

2.3.3 Calculate Element ImpactsImpact calculations determine the amount (relative or absolute) of impact a transaction between two parties points that flows on transmission elements. The term transaction is used quite loosely. A transaction may represent an interchange between two Balancing Authorities (also known as inter-BA transaction), or a generator serving a load within a balancing area, also known as intra-BA transaction. Transactions may or may not be tagged, and many times represent generation from a source point comprised of multiple generators supplying the load of a region or zone, comprised of multiple individual loads.

Relative impact is determined by the Shift Factors alone and represents the percentage of transaction between two parties points that flow on a transmission element. Absolute impact takes into account the actual transaction amounts, and is calculated by multiplying the relative impact of the transaction by the transaction MW amount.

Element impacts are calculated once every five minutes using the information from the latest state estimator solution as inputs. The impact calculations will make use of the most recent shift factors calculated by the ECC.

There are two types of impact calculations that ECC will perform. The first identifies the contribution of transactions to the flow on transmission elements. The, second identifies the impact of curtailing transactions on the flow of transmission elements; the methodology of the calculation is described but its usage will not occur and be fully scoped until Phase II. The former provides situational awareness, while the latter can be used in transmission loading relief calculations, such as the Unscheduled Flow Mitigation procedure. The differences between Situational Awareness Impact Calculations and Curtailment Impact Calculations are better explained through an example:

Suppose a system consisting of two Balancing Areas with generation and load, a transaction between the BAs, a monitored transmission element, and TDFs and LSFs to the swing bus as shown in the figure

P a g e 2 2

BPA User, 06/03/14,

Is Phase I establishing a curtailment tool or only a situational awareness model? Is this an appropriate discussion for Phase I; or more appropriate as part of Phase II or after?


Xcel: Element actual physical impacts are calculated once every five minutes using the latest state estimator solution. The ECC will parse the state estimator’s actual impact calculations using the most recent shift factors calculated by the ECC, into constituent transaction flow contributions. [Note – I revised this to be consistent with my understanding, I do not see the state estimator making any use of ECC results, but instead in this specification the state estimator results are an input into the ECC.


Xcel: Would appreciate some discussion as to when these would be used and who has the option to elect their use? Is it the TC, TP, BA or RC or each/all?

BPA User, 06/04/14,

How will ZSFs vary for BA remote resource to loads using dynamic transfer (pseudo tie) imports? Included in BA/TOP stakeholder discussions?


below.

Figure 2 – Example System for Impact Calculations

The transactions are:

Generation-to-Load (or Intra-BA transactions)

o MWGA-LA → GA provides 100 MW to LA

o MWGB-LB → GB provides 50 MW to LB

Interchange Transaction (or Inter-BA transaction)

o MWGA-LB → GA provides 50 MW to LB

A Situational Awareness impact calculation will indicate that the flow contributions from each transaction on the monitored transmission element as:

FlowGA-LA = (TDFA – LSFA) × MWGA-LA = (0.70 – 0.65) × 100 = 5 MW

FlowGB-LB = (TDFB – LSFB) × MWGB-LB = (0.60 – 0.55) × 50 = 2.5 MW

FlowGA-LB = (TDFA – LSFB) × MWGA-LB = (0.70 – 0.55) × 50 = 7.5 MW

Situational Awareness Flow = 5 MW + 2.5 MW + 7.5 MW = 15 MW

If the monitored element is congested and the transaction between GA and LB is curtailed, the Curtailment impact will not reduce the flow by 7.5 MW, which is the impact of the Interchange Transaction. Instead, since load is not curtailed, load LB will be supplied by an increase generation in GB. This impact is calculated as:

Reduce generation in GA by 50 MW: ΔFlowGA-LB = (0.70 – 0.55) × (–50) = – 7.5 MW

Increase generation in GB by 50MW: ΔFlowGB-LB = (0.60 – 0.55) × (+50) = + 2.5 MW

ΔFlow = [(TDFB – LSFB) – (TDFA – LSFB)] × MWGA-LB =

= (TDFB – TDFA) × MWGA-LB = (0.60 – 0.70) × 50 = – 5.0 MWP a g e 2 3


Xcel: Note this example is simplified and as a result creates an ambiguity. It is not clear to me why one would use a “TDF” (as defined above) for a single-generator sourced transaction. Instead why not use a “GSF” from the source BA and an LSF from the sink BA? (There are no intermediary BA POR/PODs which could impose an alternative transmission service curtailment priority in this example.) Again it would be helpful to understand when a single gen source factor would be used versus the assumption of a portfolio sale from a BA’s generation fleet.


The curtailment of the Interchange Transaction yields a reduction of 5.0 MW on the flow of the monitored transmission element.

2.3.3.1 Calculate ForecastsThe ECC will calculate a “raw” expected flow on an Eelement based on all of the component inputs known to the ECC, both tagged and untagged uses of the system. Recognizing that the data is imperfect and that other system impacts are outside of Peak’s control, there is a need to have an error calculation engine that “corrects” the raw expected Eelement flows. The process “Calculate Forecasts” simply updates the Eelement forecast flow to be the sum of the raw determined Eelement flow and an error correction MW value.

The ECC detailed design spec will define all of the requirements for the error correction and forecast calculation processes. It is possible, as indicated by the diagram, that these components reside outside of the ECC. However, that final decision will not be made until the ECC detailed design spec is complete with the vendor.

At a minimum, the ECC should be designed to allow for an error correction input per Element in order to allow this functionality in future phases of the tool.

2.4 Outputs & MechanismsOutputs are data objects (i.e. ECC Factors) produced by the ECC as a result of performing operations or calculations. Only data created by the ECC is considered an output; pass-through data, which may be specified as an Input for ECC display or reporting but not created by ECC, is not defined as an Output.

For the purpose of this specification, each of the following data elements is classified by Data Group, Data Class Name, and Description.

Detailed definitions are expected to be provided by the vendor within a system design specification or similar artifact and shall, at a minimum, include the following detail:

ECC Module – name of calculation or operation which creates the data.

Attributes – data Element details (e.g. PSBank, Name, TapPosition, LastChange, QualityCode).

Format – if applicable, expected format of the data object (e.g. CSV, XML, Telemetry).

Data Dictionary – if applicable, the database view, stored procedure, table, or query where the data may be obtained.

Frequency – expected temporal frequency of the data object (e.g. 15 minutes).

Trigger – what triggers the data to be an output from ECC.

Accuracy/Precision – defined accuracy and/or precision of the data object.

Integration – specified integration methods for retrieving data (e.g. Web Services, Pub/Sub, and ICCP).

Mechanisms specify functionality of the system for user and external application access. The following types of mechanisms are defined:

Visualization of Operational Results

User Interface and Displays

P a g e 2 4


Xcel: What are the timing implications of this? Will the capability described here for error correction be a stakeholder decision or a Peak management decision? How much experience will inform the need to procure this capability? -sjb


Xcel: Cool, I don’t think this feature was ever used in the East. It has an assumption that the source of the resupply is known, however, which is often doubtful. –sjb


Alarm Processing

Reporting

Import, Export and API

2.4.1 Visualization of Operational ResultsThe ECC must provide output to the RC System Operators (RCSO) that is meaningful to for the provides situational awareness of operations of the Peak RC area in a meaningful format. Specific requirements for ECC output and enhanced situational awareness of real-time information include:

Visualization of real-time flows on all elements and the corresponding limit Visualization of the composition of flows on an Element:

o Visualization of Dynamic Transfers (Dynamic Schedules and Pseudo-Ties)o Tagged flow MW (including NERC tag priorities) and percent of total MW flow

contribution.o Native load and intra-BA Network Integration Load service or market flow MW percent

and total MW flow contribution.o ACE, listed by BA, including percent MW and total MW flow contribution.o Reserve activation MW percent and total MW flow contribution.

Visualization of real-time flows on all Elements and the corresponding limits including a comparison of ECC calculated flows to SE flows

Summary of individual tags and other composition of flows to a particular Element that are sorted by TDF or similar impact factor.

For look-ahead (i.e. h+1, h+2, and h+3), visualization of expected flows on Eelements and the corresponding limit.

This situational awareness information must be presented in a rolled up fashion to provide a summary or overview of all Eelements defined within the ECC. Capability will exist to allow for the RCSO to drill down in to the details of each defined Element.

2.4.2 User Interface and DisplaysThis document does not detail the nuances of the ECC displays so as not to constrain the vendor’s solution design. The vendor shall recommend what displays will be implemented, including proposed screenshots where applicable. Peak RC shall approve the specification.

Display Type Description

Impact Trend This display provides a summary, per transmission priority, of tagged and untagged use for the selected time period in the ECC.

Transaction List This display provides a summary of the energy transactions in the ECC for a specified time range.

Intra-hour Transaction List

This display provides a summary of the intra-hour schedules for the current and next hours.

Next Hour Transaction List

This display provides a summary of the next hour transaction schedule changes (increasing or decreasing).

Whole Transaction List This display provides a summary of the transaction impacts on a selected element. It

P a g e 2 5

BPA User, 02/06/14,

Will this be based on 15 min blocks for 15 min. schedule increments?

BPA User, 02/06/14,

How are 15 min. schedule increments/adjustments accommodated?

BPA User, 02/06/14,

Could there be “Capacity” transactions?

BPA User, 06/02/14,

To distinguish from Energy Product code priority.

BPA User, 06/02/14,

Will Peak RC coordinate BA/TOP stakeholder input?


Brett was this your intent?


Xcel: Note – the state estimator already will provide flow visualization, no need to pay for the ECC to do this. So I assume what is desired here is a parsing of the actual flows into constituent transaction elements. –sjb


Xcel: Note – the state estimator already will provide flow visualization, no need to pay for the ECC to do this. So I assume what is desired here is a parsing of the actual flows into constituent transaction elements. –sjb

BPA User, 06/04/14,

Will BA/TOPs have access to the ECC Visual Display/operational data for their meaningful system operations? Address conflicts between tools results; alternative actions to resolve relief requirements with BA/TOP stakeholders .


provides a view of possible curtailment actions.

Current/Next Hour Whole Transaction List

This display provides a summary of the transaction current and next hour impacts on a selected element. It provides a view of possible curtailment actions.

Net Interchange This display provides a summary of the export, import and net MWs of an RC and BA.

Element TDF This display provides the TDF on a user specified element for hypothetical transactions between selected source and/or sink BAs. This display also provides the entry point for viewing LODFs (Line Outage Distribution Factors).

Element LODF This display provides the LODFs (Line Outage Distribution Factors) on a user specified element. The LODFs represent the effect of branch outages on the element flow on LODF elements defined.

Source/Sink TDF This display provides element TDFs for hypothetical transactions between selected source and/or sink BAs.

Source/Sink Availability [Place holder]

Element GSF [Place holder]

Element GLDF This display provides the Generation-to-Load distribution factors (GLDF) on a user specified element for a given BA. The GLDF is the impact on the element for a generator in a given BA to provide the native load or network integration load of the same control area. Only the generators with a GLDF impact greater than GLDF Cutoff% and the next-hour matrix are shown on this display.

CA GLDF This display provides the user with a list of elements that are impacted by GLDF Cutoff% or more by the control area GLDF.

Generator GLDFThis display provides the Generation-to-Load Distribution Factors (GLDF) from a user specified generator to a user specified Service Point (SP), or to a list of all service points. The GLDFs give the impact on all elements for the generator serving load within the service point area. Only the generators with a GLDF impact greater than the user entered GLDF Cutoff % and the next-hour matrix are shown on this display.

The Generator GLDF on an element for the load at the service point is calculated as the GSF (Generation shift factor) minus the LSF (Load Shift Factor) for that flowgate. The Service Point (SP) defines the area used to calculate the LSF. This may be a BA, a marginal zone or a specific bus, depending on the level of granularity at which the SP is defined and which SP is selected.

Generator Inc/Dec GSFThis display provides the Generation Shift Factors (GSF) for a user specified pair of Incrementing & Decrementing generators. The GSFs give the impacts on a list of elements for the pair of generators specified.

P a g e 2 6


Xcel: If this is the intended use of the GSF, then perhaps is should be termed a “Redispatch Shift Factor” or “RSF” so as not to tempt market participants or operators into assuming the use of this factor is with respect to delivery transactions flow impact calculation. –in other words, need to be clear that the use of this RSF to to evaluate manual redispatch effects assocated with curtailment response, and not as an input in the the transmission service curtailment calculations. – sjb

BPA User, 06/04/14,

Current UFMP uses 105 impact, BPA also uses 10% impact.

BPA User, 04/06/14,

Clarify why 5% impact.

BPA User, 04/06/14,

Clarify why 5% impact? Current UFMP uses 10% impact, BPA tools also use 10% impact

BPA User, 04/06/14,

BAs should be able to define the components that go into the GLDF impacts (for example, the granularity of the generator and service point groupings). Address in BA/TOP stakeholder discussions.


The Generator GSF on an element is calculated as the GSF of the INC Generator minus the GSF of the DEC Generator for that flowgate. Only elements with resulting GSFs impacts at or greater than the user entered GSF Cutoff % are shown on this display.

The following minimum requirements, however, are defined as general requirements for the user interface (UI):

UI shall be based on open standards and/or common UI programming language.

Displays shall have the appearance of a normally accepted web based or thick-client graphical user interface (GUI).

The UI shall be capable of presenting multiple and configurable views (e.g. tabular data views, configurable graphs) to present the data as applicable to the display’s purpose.

Displays shall be consistent with a common look and feel.

Displays shall have the capability of accessing and displaying data from various sources and applications.

The user interface shall be independent of applications and databases.

Displays shall be accessible via toolbar buttons, regular display buttons or hot links. The user interface shall provide the following features:

o Tabular displays that support paging, sorting, and data filtering.

o On-screen data entry validation.

o Program and functional execution from within the displays.

o Displays shall be protected by security features including login/logoff and configurable screen obfuscation after a configurable time period of inactivity. This feature shall be independent of any screen-saver option native to the operating system of the workstation.

o As defined in §Error: Reference source not found, Aaccess to data and displays controlled by user access/authorization rights.

o Configurable menu functions.

o Capability to enable Side-by-Side displays.

o Dates/calendar functions.

o Configure displays to hide/unhide columns or display items

o Shall permit multiple windows to be viewed concurrently on the same monitor.

o The windows shall be displayable in either overlapping or tiled.

o All displays and screens shall be functionally capable of supporting multiple monitor configurations, extended or mirrored, from a single workstation.

Consistent user interface procedures shall be provided to initiate application execution, insert data, annunciate errors, and display and report results from application programs.

P a g e 2 7

BPA User, 03/06/14,

Is congestion management a function of Phase I, Phase II or other? Who determines “user specific values”, BA/TOP or RC? If RC, how will conflicting INC/DEC GSFs be resolved between ECC tool and BA/TOP administered tools? Address with BA/TOP stakeholders.


Displaying and Rendering Data shall consider:

o Analysis-type displays shall be similar to those of the IDC.

o Appropriate displays to query all registered Eelements and allowing filtering capabilities based on the information contained in Element displays.

o Calculate flow impacts by different uses of the system and mitigation responsibilities for Qualified Transfer Paths or any defined Element with an associated limit.

o The toolset must display, alarm and notify the RC once flow is exceeding the defined threshold for an Element.

o A list of each Element that has an active mitigation decision should be displayed for the current operating hour and for the next 3 hours.

o ECC shall have the ability for users to enter a query in order to determine impacts. The query must allow for the user to select from a list of attributes including Source, Sink, Regional zone/Sub-zone, POR/POD, and monitored Element and a result set that can be sorted should be provided with information regarding the impacted zones, POR/POD, and monitored Eelements with TDF values.

Voice of Customer – The following displays and screens represent stakeholder (RCs and BA/TOPs) input and preferences. Where technically feasible, vendor should consider the following:

Main Screen or Display – consisting of the following Menus:

1. Registry (BA, TOP, PSE, POR/POD, Source/Sink)

2. Model (Transfer Distribution Factors, Generator Shift Factors, Qualified Paths, Competing Paths, Qualified Path Operators, Zones, Phase Shifters)

3. Flow-based Study (Flow-based Study Paths, Mapping Study Path, Transfer Distribution Factors, Transaction Contribution, Generation Shift Factors)

4. Mapping (Qualified Paths, Source/Sink(zones), BA(default Zone), Registry BA(Model BA), DC Line Source/Sink(POR/POD), PST (BA Source/Sink), PST (POR/POD)

5. USF (Summary, Issue, Study)

6. Tools (Transactions, Transaction Contribution)

7. Logs

8. Misc. (Documentation, Options, Close)

Alarm Summary Screen or Display – alarm Summaries should be made available. The alarm summary should include unacknowledged alarms only.

Alarm Log Screen or Display – alarm Logs should be made available. The alarm Log should include all alarms, the time it was acknowledged, and the username that acknowledged the alarm.

2.4.3 ECC Alarm ProcessingThe system shall have the ability to configure and manage alarms such that the alarm conditions are reported in a clear, concise, and timely manner to the operators. At a minimum, alarms shall be available for the following conditions:

P a g e 2 8


Exceedances of an Element SOL (current hour or future hour).

fFailure of data transfer into or out of the ECC.

When curtailment is required to be acknowledged and approved, alarms should be easily identifiable with the ability to set sound, color, and acknowledgment required for displayed messages. Alarm notification should be easily transportable through email or web interfaces and leverage common standards (e.g. using XML) to allow for monitoring outside of ECC. All alarm messages should be logged and retained for audit and compliance purposes.

Peak will work with OATI to determine appropriate alarming needed in Phase I versus Phase II; the detailed design spec for Phase I will cover alarm processing details.

2.4.4 Logging and ReportingThe system shall have the ability to provide historical reporting on all ECC calculations and alarms. Standard report functions shall allow the following:

Number of ECC alarms.

Alarm description.

Relief requested (MW) and achieved.

List of e-Tags curtailment and Generation redispatch required (to be implemented in Phase II).

The system design shall accommodate the ability to either create custom reports (i.e. Business Intelligence capabilities) and/or support third-party reporting tools (e.g. Crystal Reports).

3 External Access, Controls, and Administration

3.1 Import, Export and APIThe system shall have the ability to export any data from any screen, display, or report. At a minimum, the following export formats shall be supported:

o Microsoft Excel File Format

o Comma-Delimited File Format

o Tab-Delimited File Format

o XML File Format

Users of the system shall have the option to select formats from an export dialog.

Importing data, considering the same formats as export functionality, shall be considered by the vendor to accommodate circumstances when integration methods for input data are inoperative.

ECC output data must be made available to external applications through an Application Programming Interface (API). The API shall be able to access necessary information for storage and visualization in other Peak systems.

At a minimum, the following data classes shall be available via the API:

Element MW flows and the components that contribute to the Element flow:P a g e 2 9

BPA User, 03/06/14,

Use BA/TOP stakeholder process to coordinate Import/Export data formats with BAs/TOPs and GOs/GOPs.

BPA User, 06/02/14,

Is curtailment/redispatch a function of Phase I, Phase II or other?


Xcel: I strongly discourage reliance on the ECC for alarming with respect to an SOL violation. The Peak State Estimator should be the sole resource used for that purpose, and this tool should be used to address getting out of an SOL. This feature will place too much error correction cost on the project and make the tool into something it is not good a providing in comparison to the state estimator/security analysis. -sjb


o Tagged MW flow

o MW flow as contributed by Area Control Error

o Untagged transmission flows

o Reserve activations

Look ahead (i.e. h+1, h+2, and h+3) Element MW flows

Alarms

3.2 SecurityThe vendor shall define how security controls will be implemented, including any interpretation of NERC CIP standards. Peak RC shall approve the specification.

3.2.1 User Roles, Rights, and AccessPhase I of the ECC focuses solely on improving situational awareness for Peak RC. Current WebSAS users will continue to access the same WebSAS system as today. The user roles below are needed to support the phase I operation of the ECC are as follows:

RC System Operators (RCSO)

RC Engineers

Entities with current WebSAS role credentials shall be able to see summary data available in the ECC. Those entities shall also have access to view real-time and hours one through three (i.e. h+1, h+2, and h+3) data associated with any of the active elements.

The ECC shall have the functionality for the administrator to designate ECC access and authorization (i.e. screens, displays, menus, function, or data) based on individual roles and/or users.

The ECC Administrator shall have the ability to also provide individual users or roles access to ECC situational awareness displays and data. Detailed definitions are expected to be provided to the vendor prior to a system design specification, or similar artifact; Peak RC shall provide to the vendor roles for the ECC. Phase II

Nnon-RC user roles, rights, and access will be determined with the other design details necessary for that phaseduring both Phase I and Phase II..

3.3 ECC AdministrationECC application shall have administrator functions available only to an administrative role. Specific functions are contingent upon the vendor’s system design and shall consider the following functionality:

Controlling (i.e. add/modify/deactivate/delete) users and roles for localized and/or remote access.

Depending on the vendor’s solution design, the following functionality shall be limited to the administrator role.

o Managing Eelements

o Managing reference data links and/or metadata.P a g e 3 0

BPA User, 06/02/14,

RC process should seek BA/TOPs stakeholder input.

BPA User, 02/06/14,

Scope and RC stakeholder process should address plans for expanding user access, including to BA/TOPs.

BPA User, 03/06/14,

Current WebSAS credentials are limited (e.g., BPA’s 3 certifications are for Real Time schedulers, and are not available to Dispatchers). ECC should be available to a wider range of users. Discuss as part of BA/TOP stakeholder process.

BPA User, 06/03/14,

Recommend regional technical meetings to determine methodology for Untagged flows.


o Stop/start/reinitialize services or daemons.

o Startup parameter configuration.

o Network data storage locations (i.e. SAN storage or Directory Files Shares).

o Ability to add/delete user rights and roles.

The vendor shall define how administrative controls will be implemented; Peak RC shall approve the specification.

3.4 ControlsControls define the processing, operation, or execution of the ECC. The defined controls specify how or what the vendor shall consider for the design and/or architecture of the system. Controls include the following types:

1. Security Considerations -- requirements of the system specific to access and use-authorization of the ECC by either a user/entity or another application.

2. User Roles, Rights, and Access – defined roles of users of the ECC.

3. Use Cases– process requirements which define execution of user steps and routing of data and/or information in sequence (e.g. review and approval).

4. Administration – requirements of the system specific to the administration of the ECC.

The ECC vendor detailed design spec must address each of the controls.

4 Performance Metrics

The following section defines minimum metrics for ECC use and operation. Peak expects the detailed design document from OATI will address these areas; Peak will review and negotiate areas of concern.

4.1 PerformanceThe following performance metrics are required functionality for the ECC.

The ECC shall be able to support 15 concurrent phase I Peak RC users. However, the system must be built to be scalable to support all webSAS users and future growth in users as the ECC is developed.

ECC shall support the following simultaneous user types in phase I, by role without a degradation in performance:

o RCSO, 10

o RC Engineer, 4

o Applications Support (IT), 1

Future phases of the ECC project will incorporate additional user roles when webSAS functionality is brought into the ECC (Phase II), as well as if and when congestion management curtailment and redispatch capabilities are expanded and is brought into the ECC (Phase III or later?). The system must

P a g e 3 1

BPA User, 06/02/14,

ECC interface displays, and output should be available to all WECC BA/TOPs.

BPA User, 06/03/14,

RC process should seek BA/TOPs stakeholder input to address, among other things, RC/BA/TOP roles and responsibilities including process for resolving conflicts between RC and BA/TOP situational awareness results, and conflicts between ECC and BA/TOP congestion management tools regarding alternative curtailment and redispatch actions to meet relief requirement. Stakeholder process should clearly distinguish conditions when RC communications provide guidance or direction and provide the parameters for both.


be scalable to ensure acceptable system performance when the additional users are introduced to the system.

ECC shall ensure that the response time from when a request or transaction is initiated by a user, to the time an application response is returned, will be less than 3 seconds for 95% of all transactions, measured at a Local Area Network, and not subject to external limitations, such as Internet availability and performance. This performance requirement does not include shift factor and future curtailment calculations. OATI will provide the performance expectations of the system, such as response time to user actions, based on varying user loads. Peak will review those expectations and request modifications as needed.

4.2 AvailabilityThe ECC is expected to demonstrate a minimum availability of 99.5%. This means that the system is designed for high availability, with appropriate fail-over and redundancy designs.

ECC shall be available 24 hours a day, 7 days a week. with the exception of scheduled and unscheduled downtime.

ECC shall be reliable with respect to functionality and data integrity. ECC will go through testing and, upon acceptance by Peak RC, it must perform according to approved specification.

ECC shall maintain unscheduled downtime per year less than or equal to 10 hours, unless mutually agreed by vendor and Peak RC.

For unscheduled downtime, vendor shall initiate repair in less than or equal to 1 hour.

Vendor shall limit scheduled downtime per year less than or equal to 20 hours, unless mutually agreed by vendor and Peak RC. Scheduled downtime shall not count towards expected availability.

Vendor shall notify Peak RC of the ECC’s unavailability if the system becomes unavailable for normal operations due to any reason, including both scheduled and unscheduled maintenance. Notification shall include the following:

o The reason for the downtime

o When the down time will start

o When the down time will end

o Contact number for vendor support

4.3 Data RetentionThe following requirements are specific to ECC data retention including operational data (i.e. Inputs/Outputs) and audit data.

ECC shall support data retention of all transactions made for five years, except for extremely large volume data, such as Shift Factors (GSF, LSF, TDF, etc.). Shift Factors must be retained for a minimum of 30 days.

Input data for ECC operations shall be retained 24 hours in a rolling data store.

P a g e 3 2


BC Hydro: It may be valuable to add a section on Reporting & Data Archiving in the document. Peak may find that the data that is retained for only a rolling 24 hour data store and 30 day store may not be available when it commences an investigation of an event resulting in the compilation of a report on the issue. Since reports are compiled after the event has occurred, the current data retention requirements set out in the spec may hinder comprehensive reporting capability. BC Hydro believes it is prudent to contemplate the subject of reporting and data archiving now as opposed to later when it may be too late or too costly to incorporate these additional requirements.


Xcel: Need to define what reliability means prior to signing the deal and to perform acceptance testing.

BPA User, 06/02/14,

Testing should engage BA/TOP stakeholders.


Xcel: This is meaningless – if both are excepted, there is no availability requirement!] I noticed the caps on scheduled downtime below, but what performance trigger, cost mitigations occur for unacceptable unscheduled downtime? That should be part of the contract negotiation. – sjb

BPA User, 02/06/14,

Detail for the BA/TOP stakeholder process.


Xcel: [I thought this was replacing webSAS, why would that functionality be brought into the tool?


Appendix A: Terms, Acronyms, and DefinitionsThe following terms and acronyms are used is this document.

Term Definition

ACE Area Control Error

BA Balancing Authority

BES Bulk Electric System

CA Control Area

CIP Critical Infrastructure Protection

COS Coordinated Outage System. Coordinated Outage Scheduling System is the Transmission and Generation outage scheduling system used by Peak to collect and manage scheduled outages for the Peak RC area.

CSV Comma Separated Values

DC Direct Current

Dynamic Schedule

A time-varying energy transfer that is updated in Real-time and included in the Scheduled Net Interchange (NIS) term in the same manner as an Interchange Schedule in the affected Balancing Authorities’ control ACE equations (or alternate control processes). (Definition approved by NERC BOT but not FERC.)

Dynamic Transfer

The provision of the real-time monitoring, telemetering, computer software, hardware, communications, engineering, energy accounting (including inadvertent interchange), and administration required to electronically move all or a portion of the real energy services associated with a generator or load out of one Balancing Authority Area into another.

ECC Enhanced Curtailment Calculator

EIDE Electric Industry Data Exchange. Electric Industry Data Exchange is an XML communications protocol utilized by WECC entities, including Peak RC.

EIR Electric Industry Registry

Element Any electrical device with terminals that may be connected to other electrical devices such as a generator, transformer, circuit breaker, bus section, or transmission line. An Element may be comprised of one or more components.

FDS Functional Design Specification

GLDF Generation-to-Load Distribution Factors

GSF Generation Shift Factors

GTL Generation to Load

GUI Graphical User Interface

I/O Inputs and Outputs

ICCP Inter-Control Center Communications Protocol

P a g e 3 3

BPA User, 04/06/14,

Per WECC and NERC Dynamic Transfer Reference Guidelines, Dynamic Transfers are tagged transactions as either dynamic schedules or pseudo tie tags. This definition appears to be describing Pseudo Ties.


Term Definition

ICOM Inputs, Controls, Outputs, and Mechanisms

IROL Interconnection Reliability Operating Limit

LODF Line Outage Distribution Factors

LSF Load Shift Factors

MW Megawatt

NAESB North American Energy Standards Board

NERC North American Electric Reliability Corporation

NI Network Integration

NL Native Load

NSI Net Scheduled Interchange

OATT Open Access Transmission Tariff

OTDF Outage Transfer Distribution Factors

POD Point of Delivery

POR Point of Receipt

PSE Purchasing-Selling Entity

Pseudo-Tie A time-varying energy transfer that is updated in Real-time and included in the Actual Net Interchange term (NIA) in the same manner as a Tie Line in the affected Balancing Authorities’ control ACE equations (or alternate control processes). (Definition approved by NERC BOT but not FERC.)

PST Phase-Shifting Transformer

PTDF Power Transfer Distribution Factors

PTP Point-to-Point

Pub/Sub Publish and Subscribe

RC Reliability Coordinator

RSG Reserve Sharing Group

SAN Storage area network

SE State Estimator. State Estimator is a real-time application used by Peak Reliability to determine the “state” of the Western Interconnection. The SE solution results includes system topology, generator outputs, line/transformer flows, load values, transformer and phase shifter tap positions, etc.

SOL System Operating Limits

TDF Transmission Distribution Factors

P a g e 3 4


Term Definition

TLR Transmission Load Relief

TOP Transmission Operator

TP Transmission Planner

TRM Transmission Reliability Margin

TSP Transmission Service Provider

UFM Unscheduled Flow Mitigation

UFR Unscheduled Flow Reduction

UI User Interface

USF Unscheduled Flow Relief

WECC Western Electricity Coordinating Council

WIT WECC Interchange Tool. The Western Interchange Tool is a system to facilitate and coordinate interchange between WECC Balancing Authorities (BAs). The WIT will also provide Interchange scheduling information to Peak RC.

WSM West Wide System Model. West-wide System Model is the base model that is created once every 4-6 weeks by Peak RC. The WSM does not contain real-time information; rather it contains the basic system connectivity, equipment attributes, and other general power system modelling information.

XML Extensible Markup Language

ZSF Zonal Shift Factor

P a g e 3 5

introduction - web viewthe gtl calculation shall form the basis for determining a ba relief...

Documents