· Web viewThis document was developed by Peak Reliability (Peak) in consultation with the ECC Task Force to define minimum functional requirements for the …

DRAFTVersion 12

Enhanced Curtailment Calculator (ECC)Functional Requirements

By

Peak ReliabilityWith support from the ECC Task Force

MMM DD, YYY

ECC Tool Functional Definition

Table of Contents

1 Introduction.................................................................................................................4

1.1 Phase I versus Phase II.......................................................................................6

1.2 What this Document Defines................................................................................6

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

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

2.1 Data Flow.............................................................................................................9

2.2 Inputs...................................................................................................................9

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

2.2.2 State Estimator Savecase Data..............................................................12

2.2.3 ECC Model..............................................................................................12

2.2.4 ECC Element Definitions.........................................................................13

2.2.5 Mapping WSM to ECC............................................................................13

2.2.6 Real-Time Data.......................................................................................13

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

2.2.8 Look-Ahead Data Inputs..........................................................................15

2.3 ECC Element and Calculations Processes........................................................16

2.3.1 Element Management Process...............................................................17

2.3.2 Calculate Shift and Distribution Factors..................................................20

2.3.3 Calculate Element Impacts......................................................................23

2.4 Outputs & Mechanisms......................................................................................25

2.4.1 Visualization of Operational Results........................................................26

2.4.2 User Interface and Displays....................................................................28

2.4.3 ECC Alarm Processing............................................................................32

2.4.4 Logging and Reporting............................................................................33

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

3.1 Import, Export and API.......................................................................................33

3.2 Security..............................................................................................................34

3.3 User Roles, Rights, and Access.........................................................................34

3.4 Non-RC User Access.........................................................................................35

3.5 ECC Administration............................................................................................35

3.6 Controls..............................................................................................................35

P a g e 1


3.7 Documentation...................................................................................................36

4 Performance Metrics.................................................................................................36

4.1 Performance......................................................................................................36

4.2 Availability..........................................................................................................36

4.3 Data Retention...................................................................................................37

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

P a g e 2


1 Introduction

This document was developed by Peak Reliability (Peak) in consultation with the ECC Task Force 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 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, 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 it is also envisioned that the RCSOs will have the ability to initiate curtailments, if 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 unacceptably high flows that are 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 have the RC use the ECC to initiate curtailments and identify redispatch requirements necessary to relieve the condition. Any curtailments or redispatch requirements initiated by the ECC will be done in a fair and equitable manner according to the methodology and rules programmed into the tool; the methodology and rules will be consistent with the FERC pro forma tariff.

The current Western Interconnection 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 (UFMP). While the webSAS tool manages congestion only on the six Qualified Paths consistent with the current approved methodology, 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 and update monitored 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. Any proposed modifications to the approved methodology or current UFMP will undergo a stakeholder vetting process prior to implementation as part of Phase II.

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.

P a g e 3


P a g e 4


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 congestion management 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

o , 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 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 tagged or untagged Dynamic Transfers.

Interface with e-Tag systems for Interchange Transactions information required by the ECC.

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

1.3 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.

Detailed definition of data inputs and outputs (I/O).P a g e 5


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 changes to mitigation procedures in the stakeholder process.

P a g e 6


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 7

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 8


Source of Record

Data Type Description

Coordinated Outage System (COS)

Generator Scheduled Outage Information

Forecasted and actual generator outages and derates provided to Peak by TOPs or BAs.

Coordinated Outage System (COS)

Transmission Scheduled Outage Information

Forecasted transmission outages provided to Peak by TOPs or BAs.

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 Balancing Authority Area. The default data is the entire BA Area, but entities may work with Peak to define sub-BA areas to forecast, but Peak at a minimum would require the BA Area forecast.

NAESB EIR Registry

Mapping of Source/Sink and POR/POD data

Mapping will require a manual process by the BAs.

OATI Tagging System

E-Tag Data E-Tag source/sink and/or POR/POD data, MW profile, transmission priority, and other relevant data for tagged transactions

OATI Tagging System

Net Scheduled Interchange

Net Scheduled Interchange profile for current and look-ahead hours.

OATI Tagging System / EIDE

Next-Hour Dynamic Transfers

Forecasted intra-hour coordinated transfer of energy between BAs.

Registration Reference Data

JOU Allocations (fixed)

Fixed percentage provided by Peak 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.

P a g e 9


Source of Record

Data Type Description

SCADA BA ACE Offset Value for RSG Response

Real-time telemetered data of the ACE offset used by any BAs in response to their participation in a RSG event

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.

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 to generator outages.

West-wide System Model

System Topology Modeled system topology for the Western Interconnection.

P a g e 1 0


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 Common Information Model (CIM) format (or another selected format as defined through system design between OATI and Peak.) The WSM base model will include typical modeling attributes including, but not limited to:

Unique identifiers for equipment

Topology, including equipment connectivity

Line and transformer impedances

Generator maximum and minimum outputs

Transformer and phase shifter tap ranges

2.2.2 State Estimator Savecase DataPeak runs a state estimator (SE) using the WSM with over 125,000 measurements mapped to the network model. The ECC will read a new set of state estimator data provided by Peak once every five minutes. The SE data provided to the ECC will be the system states in a prescribed format that can be applied to the WSM base model. The actual SE data set will be provided to OATI every five minutes via the secure file transfer protocol (SFTP) or other mechanism as agreed between OATI and Peak IT.

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

Transmission line and transformer limits

Interface MW flow

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 1


2.2.4 ECC Element DefinitionsThe ECC will have the capability to model any Element of the WSM for monitoring of 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 including generation, DC line, or phase shifter as contingencies . The individual facilities that make up an Element must exist in the WSM to be defined for use in the ECC. Some elements, such as jointly owned units (JOUs) or loads pseudo-tied between BAs, may require additional details in their ECC modeling definitions. The process around managing Elements in the ECC is defined in a later section of this functional specification.

2.2.5 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 or Generating Station to a source name. The display to create this cross-linked mapping will be built in the ECC and maintained by Peak. 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. Peak will package any real-time SCADA data in a format agreed upon with OATI and submit to the ECC via SFTP.

The ECC will monitor Dynamic Transfers to give maximum situational awareness of their impacts on ECC Elements. Specific requirements for Dynamic Transfers include the following:

The ECC will utilize real-time telemetry on Dynamic Transfers that is provided to the ECC via SCADA data in order to monitor current hour impacts.

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

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 – the real time ACE values for every BA within Peak’s footprint will be made available to the ECC every five minutes.

P a g e 1 2


RSG – the ACE offset values for BAs within Peak will be made available to the ECC every 5 minutes.

2.2.7 Scheduled Flow (e-Tags)The ECC will read e-Tags for impacts in the current operating hour as well as for the 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.

The base set of e-Tag data will be utilizing Approved and Implemented status e-Tags. To improve accuracy of look-ahead hours, the ECC will have the optional ability to assess the impacts of e-Tags in the Pending status.

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.

For current hour, real-time values of the Dynamic Schedule are provided to the ECC for more accurate assessment of the actual Dynamic Schedule impact to Elements.

Transmission priority from Dynamic Schedule e-Tags will be available for usage by the ECC. In Phase II, this same information can 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 becomes effective on October 1, 2014, Pseudo-Ties must either submit an e-Tag or submit similar information to congestion management tools. Peak’s preference is for entities to submit e-Tags on Pseudo-Ties to obtain this information. 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 (current and forecast) Transmission Priorities for the Pseudo-Tie path

Peak will work with stakeholders on an acceptable mechanism to collect this data and then pass it to the ECC.

P a g e 1 3


2.2.8 Look-Ahead Data InputsThe 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). All of these look-ahead data inputs, except NSI, will be supplied to the ECC on at least hourly frequency, and the ECC will support data at hourly interval granularity or broken into 15-minute interval granularity. The NSI forecast will be supplied to the ECC on a five minute frequency.

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 three hours are also provided to the ECC. Logic to determine whether to take the SE status as return to service prior to the end of an outage time (or SE status to force an outage prior to the start time of an outage) needs to be developed between Peak and OATI. A user configurable parameter must be available within the ECC to allow for all inages to be included or excluded from one or more look-ahead hours. A similar user configurable parameter must be available within the ECC for outages. Additionally, individual inage or outage events must have the ability to be flagged to override the default system parameters for inclusion or exclusion in some or all look-ahead hours. The ECC should monitor the COS-supplied data versus SE equipment status and log within the ECC those mismatches in status.

Load Forecast – Balancing Authority Area load forecast for hours one, two and three will be provided to the ECC. The ECC will calculate the input load forecast error correction and apply that load forecast correction factor for each individual BA going forward into hours 1 through 3. The load forecast correction factor is calculated as the difference between the current SE area load and the corresponding real-time value provided by ICCP. The ECC will be able to support and utilize load area forecasts on a more granular level. The ECC will perform basic load forecast data validation, including, but not limited to, identifying a load forecast value of zero and identifying a load forecast value unreasonably larger than a BA’s maximum historical load. If a value is identified to be invalid by the ECC, it will be replaced in the ECC by the previous interval’s value. Peak will work with OATI to develop a proper set of validations.

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 (unit or plant). The preference is to obtain forecasts for every generating unit that is defined within the WSM, but the forecast may be provided as an aggregate generating station forecast if the individual unit granularity does not exist. The ECC will need the ability to divide generating station forecasts into unit forecasts if the WSM modelling is to that granularity. The ECC will not perform any smoothing or correcting of the generation forecast values; however, the ECC will have the ability to validate generation forecasts (e.g. generation forecasts greater than a unit’s or generating station’s maximum output). If the ECC determines a value to be invalid, it will be replaced in the ECC by the previous interval’s value. Peak will work with OATI to develop a proper set of validations.

NSI Forecast – Net Scheduled Interchange per Balancing Authority Area is to be provided as an input to the ECC from the OATI tagging systems. The NSI forecast will be provided to the ECC in two different formats. The first NSI forecast will include only approved e-Tags. The second NSI forecast will include both approved and pending e-Tags. The NSI forecast will show profile

P a g e 1 4


changes over time based on the aggregated values of all the included e-Tags. Updated NSI forecast data will be obtained every 5 minutes when the new SE data is loaded.

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

2.3.1 Element Management ProcessThe Elements 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 Elements 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. Enable/Disable an Element

3. Modify an Element

4. Deactivate an Element

5. Delete an Element

6. Auditing an Element

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 ECC should have the flexibility to allow/disallow non-RC entities the ability to create Elements based on RC controlled permission sets. These permissions will be configured in the ECC as the business processes are defined in the future.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.

The ECC must have the ability to create temporary Elements as needed to monitor system conditions of interest based on other real-time assessments.

P a g e 1 5


2.3.1.2 Enable/Disable an ElementThis use case represents the RC’s ability to on the fly enable or disable an Element for impact calculations. This will be a primary method for disabling unnecessary calculations for Elements that are not needed given a specific set of operating conditions.

The ECC should have the flexibility to allow/disallow non-RC entities the ability to

enable/disable Elements based on RC controlled permission sets. These permissions will be configured in the ECC as the business processes are defined in the future.

The act of enabling/disabling an element for impact calculations shall be recorded in an audit log including all entry fields as well as the user information.

2.3.1.3 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 ECC should have the flexibility to allow/disallow non-RC entities the ability to modify Elements based on RC controlled permission sets. These permissions will be configured in the ECC as the business processes are defined in the future.

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.4 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 ECC should have the flexibility to allow/disallow non-RC entities the ability to deactivate Elements based on RC controlled permission sets. These permissions will be configured in the ECC as the business processes are defined in the future.

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.

P a g e 1 6


2.3.1.5 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.

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

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

2.3.1.6 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 shall approve the created/modified/deactivated Element. The RC approval will be impacted by the permissions developed for non-RC entities to create, enable, disable, modify, or deactivate an element as described in the previous sections.

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 Comments captured during RC create/modify/deactivate actions

o Effective date/time of the Element create/modify/deactivate action

The 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 or added.

P a g e 1 7


.

2.3.1.7 Auditing 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 Elements.

Audit approver actions and data entry for created 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 and Distribution Factors Shift factors are the most basic calculation performed within the ECC. There are a variety of shift factors calculated, some describing the impact on Elements from a single generator, others describing the impact on Elements from a group of generating resources.

Every 15 minutes, shift factors will be calculated for each 15 minute interval over a rolling two hour window from T0 through hour ending T0+2 with a single factor calculation used for all of hour T0+3. The two hour window will advance once the top of the next hour is reached.

For a subset of flagged “priority” flowgates, shift factors will be calculated for each 5 minute interval over a rolling two hour window from T0 through hour ending T0+2 while still maintaining a single factor calculation for use during hour T0+3. This subset of flagged “priority” flowgates is expected to be no more than 20 percent of the potential 1,000 monitored Elements.

A near real-time state estimator solution case is provided to the ECC every 5 minutes, yet a majority of the shift factors are only calculated every 15 minutes. This difference in shift factor update timing is due to the infrequency of system topology changes occurring every 5 minutes and the fact that factor recalculation is not necessary if topology changes do not occur. The ECC will have the ability to monitor system topology sent from the SE and only recalculate the shift factors if topology changes occur. This same logic would occur in look-ahead hours where shift factor recalculation only occurs if new outages or returns to service will occur. Additionally, the ECC will have the ability for a RC user to trigger a manual run of the shift factor calculations so that major system events, such as an unplanned outage, occurring between 15 minute calculation intervals can be incorporated more rapidly into the ECC’s system awareness. 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:

P a g e 1 8


2.3.2.1 Power Transfer and Outage Transfer Distribution Factors Power Transfer Distribution Factor (PTDF) Elements are Elements 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.

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

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 monitoring for impacts on Elements.

o Example: If a tag’s calculated 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 and obtain the most current POR/POD/Source/Sink information for TDF calculations.

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

P a g e 1 9


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

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:

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 Network Integration (NI) and Native Load (NL) services to be treated comparably with non-firm and firm Point-to-Point (PTP) type transactions during transmission service evaluations. The ECC assists the RC in allocating appropriate relief of all PTP type transactions and GTL impacts in order to ensure comparable curtailment and/or redispatch.

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 redispatch 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 monitoring Element impacts for situational awareness.

GLDFs shall be shown in the Element GLDF display and the CA GLDF display in the ECC.P a g e 2 0


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 the load within their own Balancing Authority Area. From this list, the user can drill down and view the generator contribution to flow.

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 Balancing Authority Area.

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

The appropriate input data must be supplied if Peak works with a BA/TOP to define a BA ZSF.

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 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 Authority 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 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, the shift factor calculations, real-time data, and look-ahead data as inputs. The Element impacts are visualized on 15 minute intervals across a rolling two hour window with a single visualization of hour ending 3. 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 Authority 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

P a g e 2 1


the figure 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 2


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 Element 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 Element flows. An example of an error correction algorithm would be a straight forward calculation, likely a “feed forward” algorithm that takes the current hour element forecast and determines the difference when compared with the real-time state estimated or SCADA value. The process “Calculate Forecasts” simply updates the Element forecast flow to be the sum of the raw determined Element flow plus the error correction MW value. The error correction can be enabled/disabled by individual users without impacting other ECC users. When the error correction is disabled, the forecasted flow will exclude the error correction component of the calculation.

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).

P a g e 2 3


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

Alarm Processing

Reporting

Import, Export and API

2.4.1 Visualization of Operational ResultsThe ECC must provide output to the RCSOs that provides situational awareness of operations of the Peak Reliability Coordinator Area in a meaningful format. The layers described below will be shown in two ways: 1) a tabular display showing each element and each contributing layer to flow for a user defined time increment (T0, T0+15, etc), and 2) upon selection of any individual element, a trend display showing each contributing layer to flow for the current hour through all future hours. Each element will be displayed along with the corresponding limit and actual flow. The layers which will be shown as impacting Elements within the ECC include:

Tagged (e-Tag) Transactions – e-Tags will be visualized as an impact to Elements. The default set of e-Tag data to use are Approved and Implemented status e-Tags. ECC users will have the ability to toggle whether Pending status e-Tags are enabled or disabled as an impact to Elements.

Dynamic Transfers – Dynamic Transfer information will be visualized on the Elements. The real-time telemetry will be used for current hour, whereas future hours will rely on forecast information from e-Tags or other sources.

ACE - The process for visualizing 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. All of the BAs with a positive ACE will proportionally send power to all of the BAs with a negative ACE, and those flows will then be reflected upon the impacted Elements. ACE impacts will be shown as impacts to Elements for 30 minutes with a calculation methodology developed by Peak and OATI to ramp the ACE impacts rather than reflecting a step change at the end of the 30 minute period. The 30 minute parameter is an administrative parameter that Peak will be able to modify globally.

RSG – Reserve Sharing Group activations are visualized within the ECC upon activation of an RSG event. RSG information necessary include ACE offset values per BA in the RSG. For Phase I, RSG will not be shown as a visualization layer per Element(s). Instead, each BA’s ACE and ACE offset will be shown in a display for awareness of when the BA is participating in a RSG event. Consideration should be given by OATI to potential Phase II implementation of RSG impacts on an Element(s) basis.

Native Load/Network Integration Load Serving – Native load/Network Integration Load served within a Balancing Authority is visualized within the ECC through the use of other inputs to the

P a g e 2 4


ECC. It will be calculated based on deductions from those inputs such as the tagged flows, actual load, and actual generation. This value is not explicitly provided to the ECC from an external source. The calculation methodology will be proposed by OATI in the detailed design.

Market Flows – Market Flows are those impacts to Elements attributed to power dispatched in a centralized market dispatching generation economically. Examples of Market Flow that the ECC will monitor include the CAISO Market as well as the Energy Imbalance Market between CAISO and Pacificorp. The ECC will calculate Market Flows similar to Native Load flows or alternately by the ECC having the inputs of what generation is dispatched in the market solution. If certain market implementations have transfer restrictions, then the Market Flow implementation would allow for setting such limits via an e-Tag or some other mechanism by which the ECC is informed of the restriction amount.

Unaccounted Element Flow – This layer will account for any flows that are not assigned to the other defined portions. Examples of power that may fall into this category include transmission losses and minor discrepancies arising from modelling or calculation issues. This value can be calculated by comparing the input SE flow to the components calculated above with the difference then being representing by this Unaccounted Element Flow.

When representing the layer information described above on Elements, the ECC must be able to meet the following technical requirements:

The ECC must be able to support up to 1,000 enabled Elements for monitoring. The ECC must allow definitions for greater than 1,000 Elements so that users can change

between the Elements which are monitored. The ECC must have the ability for the user to manually override the limit on an Element. This

functionality would provide the ability to adjust the ECC monitoring on a congested element when a temporary higher limit is available to relieve a congested Element. This manual override should automatically end after a time that can be configured by the ECC administrator.

The ECC must allow the user to choose which limit an Element uses. Facility Ratings of the monitored facility within the defined Element will be the default rating of choice, but the ECC will allow the user to choose an alternate limit for the defined Element (e.g. an interface limit) as the limit against which to monitor.

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 shall approve the specification.

Display Type Description

Dashboard This display would serve as the primary screen a user sees when opening the ECC. Optionally, the screen would update to show Elements which have congestion at a user-selected percentage. Users also would have the ability to add other Elements of interest to monitor from this main display.

Impact Trend This display provides a summary, per transmission priority, of tagged and untagged use for the selected time period in the ECC. The user would have the ability to change between a linear trending display and a bar chart display. Some impacts,

P a g e 2 5


such as ACE, may only appear in certain versions of the trend. Section 2.4.1 lists the different layers to visualize and limitations on times layers will be available for visualization.

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 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 Balancing Authority 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 Balancing Authority Area GLDF.

Generator GLDF This 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.

P a g e 2 6


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 GSF This 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.

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.

This display will be available on Elements regardless of congestion status. Users would have a study mode to choose an Element or Elements from which the ECC then identifies the INC Generator and DEC Generator lists. Users then could alter the generation levels of one or more INC Generator(s) and DEC Generator(s) to see the impact to the chosen Element.

ACE Impact Worksheet This display allows the user to study how changing one or more BA’s ACE values would impact congestion on elements. The worksheet would capture a snapshot of current ACE values for each BA, and then the user would choose an Element. The user would then have the ability to change any of the ACE values to show how those changes impact the Element. Functionality will exist to automatically bring all ACEs to zero (through a button click or similar).

RSG Visualization This display visualizes each BA’s ACE value as well as the BA ACE offset value so that ECC users are aware that a BA is responding to a RSG request or offsetting their ACE to move generation for an alternate reason.

Element Dynamic Transfer Impacts

This display provides a view of only the Dynamic Transfer (Dynamic Schedule and Pseudo-Tie) impacts to Elements. This display would show information including the real-time dispatch, max energy dispatch available under the associated transmission reservations, and any reliability caps that are imposed on the Dynamic Transfer.

Mapping Displays These displays allow mapping of relevant data between inputs to the ECC (WSM, e-Tags, etc).

Alarm Displays These displays would alert users to Elements of interest due to congestion or other defined factors. In addition, these displays will contain logging capabilities to see historical information on alarming.

Subset of webSAS displays or similar functionality

Some webSAS displays may be identified by Peak and other stakeholders during the design process with OATI as having value within the ECC. OATI will work with the Peak to move these displays or implement similar functionality into the ECC.

P a g e 2 7


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 Access 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.

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 Elements and allowing filtering capabilities based on the information contained in Element displays.

P a g e 2 8


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 Elements with TDF values.

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. Two types of alarming should be developed in the ECC. One set of alarms would indicate issues with inputs or the calculation engines of the ECC so that Peak and OATI IT support staff can resolve issues. The other type of alarming is to notify ECC users of Elements which are close to a limit.

The IT support staff alarms shall be available for failure of data transfer into or out of the ECC, issues with configuration, and issues with the ECC engine. These alarms will be sent to predefined email lists so that appropriate Peak and OATI personnel are notified on a real-time basis.

The ECC user alarms would alert users to Elements which are near or exceeding Facility Limits, including SOLs or IROLs. These levels for alarming would be configurable by each user within the ECC. User alarms can be a combination of graphical and audible in nature. Alarm notification should be transportable through flat files sent via SFTP, or another transfer mechanism agreed upon between Peak and OATI, to allow for monitoring outside of ECC. All alarm messages should be logged and retained for audit and compliance purposes.

The detailed design spec for Phase I will cover alarm processing details.

2.4.4 Logging and ReportingThe ECC will log all data around congested Elements. The ECC will log information for any Element which is above a user-defined threshold. The information which will be logged include:

Congested Element

Level of congestion reached

Start time and end time of congestion on Element

Element Flows

The system shall have the ability to provide historical reporting on all ECC events and alarms. These reports will be accessible by both Peak and non-Peak users. Standard report functions shall allow the following:

P a g e 2 9


Number of ECC congestion events per Element

Alarm description, such as max congestion reached, duration of congestion, etc.

Breakdown of congestion by layers.

Additional logging and reporting requirements may be required in Phase II design.

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:

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

A subset of user displays as defined during the detailed design process with OATI

Data from the ECC which can be sent to Peak’s EMS in a pre-defined CSV format for use in power flow simulations (e.g. such as generation MW output levels to solve congestion on an Element). This data would be exported from the generation redispatch worksheet.

P a g e 3 0


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

3.3 User Roles, Rights, and AccessPhase I of the ECC focuses solely on improving situational awareness. The user roles below are needed to support the phase I operation of the ECC are as follows:

RC System Operators (RCSO)

RC Support Personnel

Non-RC System Operators

Non-RC Support Personnel

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 Peak users or roles access to ECC situational awareness displays and data. Peak will work with OATI to define in the design documentation the various access levels and restrictions that are needed.

3.4 Non-RC User AccessThe ECC will use a similar non-RC access model as compared to the one employed by webSAS. The current entities registered as a BA, TOP, or TSP will have access into the ECC. Each entity will receive the following access:

2 concurrent users

10 digital certificates

Those access rights will be per entity even if that entity is registered as more than one of the three NERC-defined functions (BA, TOP, TSP). If a non-RC entity needs access above the level in this specification, a contract between that entity and OATI will be required to gain additional access. Entities with existing OATI digital certificates can work with OATI to use those same certificates for ECC access.

The ECC Administrator shall have the ability to also provide individual non-RC users access to ECC situational awareness displays and data. Peak will work with OATI to define in the design documentation the various access levels and restrictions that are needed.

3.5 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.

P a g e 3 1


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

o Managing Elements

o Managing reference data links and/or metadata.

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 shall approve the specification.

3.6 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.

3.7 DocumentationOATI will provide detailed documentation of the functionality of the ECC. This documentation may include user guides, training presentations, and other useful formats to train users on the ECC.

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 have a system response time of less than 3 seconds on all user displays where no calculations are performed to create the display data.

P a g e 3 2


The ECC shall be able to support 15 concurrent phase I Peak 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

The ECC also needs to support the non-RC user access requirements as described in section 3.4.

The system must be scalable to ensure acceptable system performance when additional users are introduced to the system. 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.

ECC shall be reliable with respect to functionality and data integrity. ECC will go through testing and, upon acceptance by Peak, 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.

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. Scheduled downtime shall not count towards expected availability.

Vendor shall notify Peak 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 maintain all input data provided by Peak for six years.

P a g e 3 3


ECC shall support data retention of all transactions made for six years, except for extremely large volume data, such as Shift Factors (GSF, LSF, TDF, etc.). The six years of data will be maintained for three years in an online system accessible by users through GUI and an additional three years in an offline system.

ECC will maintain Shift Factors associated to any congestion events for the same six year requirement period as other data. The data will be maintained for three years in an online system accessible by users through GUI and an additional three years in an offline system.

All Shift Factor data calculated by the ECC must be retained for a minimum of 90 days in a format accessible by users.

P a g e 3 4


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

Term Definition

ACE Area Control Error

BA Balancing Authority

Balancing Authority Area

The collection of generation, transmission, and loads within the metered boundaries of the Balancing Authority. The Balancing Authority maintains load-resource balance within this area.

BES Bulk Electric System

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

P a g e 3 5


Term Definition

GUI Graphical User Interface

I/O Inputs and Outputs

ICCP Inter-Control Center Communications Protocol

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

Reliability Coordinator Area

The collection of generation, transmission, and loads within the boundaries of the Reliability Coordinator. Its boundary coincides with one or more Balancing Authority Areas.

RSG Reserve Sharing Group

SAN Storage area network

P a g e 3 6


Term Definition

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

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 7

Documents

· Web viewThis document was developed by Peak Reliability (Peak) in consultation with the ECC Task Force to define minimum functional requirements for the …