PRC‐012‐2 – Remedial Action Schemes
Standard Development Timeline
This section is maintained by the drafting team during the development of the standard and will be removed when the standard becomes effective.
Description of Current Draft
Draft 1 of PRC‐012‐2 corrects the applicability of the fill‐in‐the‐blank standards (PRC‐012‐1, PRC‐013‐1, and PRC‐014‐1) by assigning the requirement responsibilities to the specific users, owners, and operators of the Bulk‐Power System, and incorporates the reliability objectives of all the RAS/SPS‐related standards. Draft 1 contains nine requirements and measures, the associated rationale boxes and corresponding technical guidelines. There are also three attachments within the draft standard that are incorporated via references in the requirements. Draft 1of PRC‐012‐2 is posted for a 45‐day initial formal comment period with a parallel initial ballot in the last ten days of the comment period.
Completed Actions Date
Standards Committee approved Standard Authorization Request
(SAR) for posting February 12, 2014, SAR posted for comment February 18, 2014
Standards Committee approved the SAR June 10, 2014
Draft 1 of PRC‐012‐2 posted for informal comment April 30 – May 20, 2015
45‐day formal comment period with initial ballot August 20 – October 5,
2015
Anticipated Actions Date
10‐day final ballot December 2015
NERC Board (Board) adoption February 2016
When this standard receives Board adoption, the rationale boxes will be moved to the
Supplemental Material Section of the standard.
A. Introduction
1. Title: Remedial Action Schemes
2. Number: PRC‐012‐2
3. Purpose: To ensure that Remedial Action Schemes (RAS) do not introduce
unintentional or unacceptable reliability risks to the Bulk Electric System (BES).
4. Applicability:
4.1. Functional Entities:
4.1.1. Reliability Coordinator
4.1.2. Transmission Planner
4.1.3. RAS‐owner – the Transmission Owner, Generator Owner, or Distribution
Provider that owns all or part of a RAS
4.1.4. RAS‐entity – the RAS‐owner designated to represent all RAS‐owner(s) for
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
coordinating the review and approval of a RAS
4.2. Facilities:
4.2.1. Remedial Action Schemes (RAS)
5. Effective Date: See the Implementation Plan for PRC‐012‐2.
B. Requirements and Measures
Rationale for Requirement R1: Each Remedial Action Scheme (RAS) is unique and its
action(s) can have a significant impact on the reliability and integrity of the Bulk Electric
System (BES). Therefore, a review of a proposed new RAS or an existing RAS proposed for functional modification or retirement (removal from service) must be completed prior to implementation or retirement. A functional modification is any modification to a RAS
beyond the replacement of components that preserves the original functionality.
To facilitate a review that promotes reliability, the RAS‐entity must provide the reviewer
with sufficient details of the RAS design, function, and operation. This data and
supporting documentation are identified in Attachment 1 of this standard, and
Requirement R1 mandates that the RAS‐entity provide them to the reviewing Reliability
Coordinator (RC). The RC (reviewing RC) that coordinates the area where the RAS is
located is responsible for the review. In cases where a RAS crosses one or more RC Area
boundaries, each affected RC is responsible for conducting either individual reviews or a
coordinated review.
R1. Prior to placing a new or functionally modified RAS in service or retiring an existing
RAS, each RAS‐entity shall submit the information identified in Attachment 1 for
review to the Reliability Coordinator(s) that coordinates the area(s) where the RAS is
located. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning]
M1. Acceptable evidence may include, but is not limited to, a copy of the Attachment 1
documentation and the dated communications with the reviewing Reliability
Coordinator(s) in accordance with Requirement R1.
Rationale for Requirement R2: The RC is the functional entity best suited to perform the RAS review because it has the widest‐area reliability perspective of all functional entities and an awareness of reliability issues in any neighboring RC Area. This Wide Area purview provides continuity in the review process and facilitates the evaluation of interactions among separate RAS as well as interactions among RAS and other protection and control systems. Including the RC also minimizes the possibility of a conflict of interest that could exist because of business relationships among the RAS‐entity, Planning Coordinator (PC), Transmission Planner (TP), or other entities that are likely to be involved in the planning or implementation of a RAS. The RC may request assistance
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
in RAS reviews from other parties such as the PC or regional technical groups; however, the RC will retain the responsibility for compliance with this requirement.
Attachment 2 of this standard is a checklist the RC can use to identify design and
implementation aspects of RAS and facilitate consistent reviews for each RAS submitted.
The time frame of four‐full‐calendar months is consistent with current utility and regional
practice; however, flexibility is provided by allowing the parties to negotiate a mutually
agreed upon schedule for the review.
Note: An RC may need to include this task in its reliability plan(s) for the NERC Regions(s) in which it is located.
R2. Each Reliability Coordinator that receives Attachment 1 information pursuant to
Requirement R1, shall, within four‐full‐calendar months of receipt, or on a mutually
agreed upon schedule, perform a review of the RAS in accordance with Attachment 2,
and provide written feedback to the RAS‐entity. [Violation Risk Factor: Medium] [Time
Horizon: Operations Planning]
M2. Acceptable evidence may include, but is not limited to, dated reports, checklists, or
other documentation detailing the RAS review, and the dated communications with
the RAS‐entity in accordance with Requirement R2.
Rationale for Requirement R3: The RC review is intended to identify reliability issues
that must be resolved before the RAS can be put in service. Examples of reliability issues
include a lack of dependability, security, or coordination.
A specific time period for the RAS‐entity to respond to the RC review is not necessary
because it is in the RAS‐entity’s interest to obtain an expeditious response from the
entity and thus ensure a timely implementation.
R3. Following the review performed pursuant to Requirement R2, the RAS‐entity shall
address each identified issue and obtain approval from each reviewing Reliability
Coordinator prior to placing a new or functionally modified RAS in service or retiring
an existing RAS. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning]
M3. Acceptable evidence may include, but is not limited to, dated documentation and
communications with the reviewing Reliability Coordinator in accordance with
Requirement R3.
Rationale for Requirement R4: Requirement R4 mandates that an evaluation of each RAS be performed at least once every sixty‐full‐calendar months. The purpose of a periodic RAS evaluation is to verify the continued effectiveness and coordination of the RAS, as well as to verify that requirements for BES performance following an inadvertent RAS operation or a single component failure in the RAS continues to be satisfied. A periodic evaluation is needed because changes in system topology or operating conditions that have occurred since the previous RAS evaluation—or initial
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
review—was completed may change the effectiveness of a RAS or the way it impacts the BES.
Sixty‐full‐calendar months, which begins on the effective date of the standard pursuant to
the implementation plan, was selected as the maximum time frame between evaluations
based on the time frames for similar requirements in Reliability Standards PRC‐006, PRC‐010, and PRC‐014. The RAS evaluation can be performed sooner if it is determined that material changes to system topology or system operating conditions have occurred that could potentially impact the effectiveness or coordination of the RAS. The periodic RAS evaluation will typically lead to one of the following outcomes: 1) affirmation that the existing RAS is effective; 2) identification of changes needed to the existing RAS; or, 3)justification for RAS retirement. The items required to be addressed in the evaluation are planning analyses that involve modeling of the interconnected transmission system to assess BES performance; consequently, the TP is the functional entity best suited to perform the analyses. To promote reliability, the TP is required to provide the RAS‐owner(s) and each reviewing RC with the results of the evaluation.
The previous version of this standard (PRC‐012‐0 Requirement 1, R1.4) states “… the
inadvertent operation of a RAS shall meet the same performance requirement (TPL‐001‐
0, TPL‐002‐0, and TPL‐003‐0) as that required of the contingency for which it was
designed, and not exceed TPL‐003‐0.” Requirement R4 clarifies that the inadvertent
operation to be considered would only be that caused by the malfunction of a single RAS
component. This allows security features to be designed into the RAS such that
inadvertent operation due to a single component malfunction is prevented. Otherwise
and consistent with PRC‐012‐0 Requirement 1, R1.4, the RAS should be designed so that
its whole or partial inadvertent operation due to a single component malfunction satisfies
the system performance requirements for the same Contingency for which the RAS was
designed. If the RAS was installed for an extreme event in TPL‐001‐4 or for some other Contingency or System condition not defined in TPL‐001‐4 (therefore without performance requirements), its inadvertent operation still must meet some minimum System performance requirements. However, instead of referring to the TPL‐001‐4, Requirement R4 lists the System performance requirements that the inadvertent operation must satisfy. The performance requirements listed (Parts 4.3.1 – 4.3.5) are the ones that are common to all planning events P0‐P7 listed in TPL‐001‐4.
R4. Each Transmission Planner shall perform an evaluation of each RAS within its planning area at least once every 60‐full‐calendar‐months and provide the RAS‐owner(s) and the reviewing Reliability Coordinator(s) the results including any identified
deficiencies. Each evaluation shall determine whether: [Violation Risk Factor:
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
Medium] [Time Horizon: Long‐term Planning]
4.1. The RAS mitigates the System condition(s) or Contingency(ies) for which it was
designed.
4.2. The RAS avoids adverse interactions with other RAS, and protection and control
systems.
4.3. The possible inadvertent operation of the RAS resulting from any single RAS
component malfunction satisfies all of the following:
4.3.1. The BES shall remain stable.
4.3.2. Cascading shall not occur.
4.3.3. Applicable Facility Ratings shall not be exceeded.
4.3.4. BES voltages shall be within post‐Contingency voltage limits and post‐
Contingency voltage deviation limits as established by the Transmission
Planner and the Planning Coordinator.
4.3.5. Transient voltage responses shall be within acceptable limits as
established by the Transmission Planner and the Planning Coordinator.
4.4. A single component failure in the RAS, when the RAS is intended to operate,
does not prevent the BES from meeting the same performance requirements
(defined in Reliability Standard TPL‐001‐4 or its successor) as those required for
the events and conditions for which the RAS is designed.
M4. Acceptable evidence may include, but is not limited to, dated reports or other
documentation of the analyses comprising the evaluation(s) of each RAS and dated
communications with the RAS‐owner(s) and the reviewing Reliability Coordinator(s) in
accordance with Requirement R4.
Rationale for Requirement R5: The correct operation of a RAS is important for
maintaining the reliability and integrity of the BES. Any incorrect operation of a RAS
indicates that the RAS effectiveness and/or coordination has been compromised.
Therefore, all operations of a RAS and failures of a RAS to operate when expected must
be analyzed to verify that the RAS operation was consistent with its intended
functionality and design. A RAS operational performance analysis is intended to: 1) verify RAS operation is consistent with the implemented design; or 2) identify RAS performance deficiencies that manifested in the incorrect RAS operation or failure of RAS to operate when expected. The 120‐calendar‐day time frame for the completion of RAS operational performance analysis aligns with the time frame established in Requirement R1 from PRC‐004‐4 regarding the investigation of a Protection System Misoperation. To promote reliability, each RAS‐owner is required to provide the results of RAS operational performance analyses to each reviewing RC. RAS‐owners may need to collaborate with their associated TP to comprehensively analyze RAS operational performance. This is because a RAS operational performance analysis involves verifying
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
that the RAS operation triggers and responds (Parts 5.1, 5.2) and that the resulting BES response (Parts 5.3, 5.4) is consistent with the intended functionality and design of the RAS.
R5. Each RAS‐owner shall, within 120‐calendar days of a RAS operation or failure of a RAS to operate when expected, analyze the RAS performance and provide the results of
the analysis, including any identified deficiencies, to its reviewing Reliability Coordinator(s). The RAS operational performance analysis shall determine whether:
[Violation Risk Factor: Medium] [Time Horizon: Operations Planning]
5.1. The System events and/or conditions appropriately triggered the RAS.
5.2. The RAS responded as designed.
5.3. The RAS was effective in mitigating BES performance issues it was designed to
address.
5.4. The RAS operation resulted in any unintended or adverse BES response.
M5. Acceptable evidence may include, but is not limited to, dated documentation detailing
the RAS operational performance analysis in accordance with Requirement R5.
Rationale for Requirement R6: Deficiencies, identified either in the periodic RAS
evaluation conducted by the TP in Requirement R4 or in the analysis conducted by the
RAS‐owner pursuant to Requirement R5, are likely to pose a reliability risk to the BES. To mitigate potential reliability risks, Requirement R6 mandates that the RAS‐owner develop a Corrective Action Plan (CAP) that establishes the mitigation actions and timetable to address the deficiency. If the CAP requires that a functional change be made to a RAS, the RAS‐owner will need to submit information identified in Attachment 1 to the reviewing RC(s) prior to placing RAS modifications in service per Requirement R1.
Depending on the complexity of the issues, development of a CAP might require study,
engineering, or consulting work. A time frame of six‐full‐calendar months is specified to
allow enough time for RAS‐owner collaboration on the CAP development, while ensuring that deficiencies are addressed in a reasonable time.
R6. Within six‐full‐calendar months of being notified of a deficiency in its RAS pursuant to Requirement R4 or Requirement R5, each RAS‐owner shall participate in developing a
Corrective Action Plan (CAP) and submit the CAP to its reviewing Reliability
Coordinator(s). [Violation Risk Factor: Medium] [Time Horizon: Operations Planning,
Long‐term Planning]
M6. Acceptable evidence may include, but is not limited to, a dated CAP and dated
communications with each reviewing Reliability Coordinator in accordance with
Requirement R6.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
Rationale for Requirement R7: Requirement R7 mandates the RAS‐owner(s) implement a CAP (developed in Requirement R6) that mitigates the deficiencies identified in Requirements R4 and R5. By definition, a CAP is: “A list of actions and an associated timetable for implementation to remedy a specific problem.” The implementation of a properly developed CAP ensures that RAS deficiencies are mitigated in a timely manner. Each reviewing Reliability Coordinator must be notified if CAP actions or timetables change.
R7. For each CAP submitted pursuant to Requirement R6, each RAS‐owner shall:
[Violation Risk Factor: Medium] [Time Horizon: Operations Planning, Long‐term
Planning]
7.1. Implement the CAP.
7.2. Update the CAP if actions or timetables change.
7.3. Notify each reviewing Reliability Coordinator if CAP actions or timetables change.
M7. Acceptable evidence may include, but is not limited to, dated documentation such as
CAPs, project or work management program records, settings sheets, work orders,
maintenance records, and communication with the appropriate Reliability
Coordinator(s) that documents the implementation or updating of a CAP in
accordance with Requirement R7.
Rationale for Requirement R8: Due to the wide variety of RAS designs and
implementations, and the potential for impacting BES reliability, it is important that
periodic functional testing of a RAS be performed. A functional test provides an overall
confirmation of the RAS to operate as designed and verifies the proper operation of the
non‐Protection System (control) components of a RAS that are not addressed in PRC‐005.
Protection System components that are part of a RAS are maintained in accordance with
PRC‐005. The drafting team selected a six‐calendar‐year testing interval to be consistent
with some of the maintenance intervals of various Protection System and Automatic
Reclosing components established in PRC‐005. This interval provides an entity the
opportunity to design its RAS functional testing program such that it coincides with the
testing of any associated PRC‐005 components. The six‐calendar‐year interval, which begins on the effective date of the standard pursuant to the implementation plan, is a balance between the resources required to perform the testing and the potential reliability impacts to the BES created by undiscovered latent failures that could cause an incorrect operation of the RAS. Extending to longer intervals increases the reliability risk to the BES posed by a potentially undiscovered latent failure that could cause an incorrect operation of the RAS. The RAS owner is in the best position to determine the testing procedure and schedule due to its overall knowledge of the RAS design, installation, and functionality. Functional testing may be accomplished with end‐to‐end testing or a
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
segmented approach. Each segment of a RAS should be tested but overlapping segments can be tested individually negating the need for complex maintenance schedules and outages. A correct operation of a RAS qualifies as a functional test as long as all segments operate. If an event causes a partial operation of a RAS, the segments without an operation will require a functional test within the six year interval to be compliant with Requirement R8.
R8. At least once every six‐calendar years, each RAS‐owner shall perform a functional test of each RAS to verify the overall RAS performance and the proper operation of non
Protection System components. [Violation Risk Factor: High] [Time Horizon: Long‐term
Planning]
M8. Acceptable evidence may include, but is not limited to, dated documentation of the
functional testing in accordance with Requirement R8.
Rationale for Requirement R9: The RAS database is a comprehensive record of all RAS existing in a Reliability Coordinator Area. The database enables the RC to provide other entities high‐level information on existing RAS that can potentially impact the entities’ operational and/or planning activities. Attachment 3 lists the minimum information required for the RAS database, which includes a summary of the RAS initiating conditions, corrective actions, and System issues being mitigated. This information allows an entity to evaluate the reliability need for requesting more detailed information from the RAS entity identified in the database contact information. The RC is the appropriate entity to maintain the database because the RC receives the required database information when a new or modified RAS is submitted for review.
R9. Each Reliability Coordinator shall update a RAS database containing, at a minimum,
the information in Attachment 3 at least once each calendar year. [Violation Risk
Factor: Lower] [Time Horizon: Operations Planning]
M9. Acceptable evidence may include, but is not limited to, dated spreadsheets, database
reports, or other documentation demonstrating a RAS database was maintained in
accordance with Requirement R9.
C. Compliance
1. Compliance Monitoring Process
1.1. Compliance Enforcement Authority:
As defined in the NERC Rules of Procedure, “Compliance Enforcement Authority”
means NERC or the Regional Entity in their respective roles of monitoring and
enforcing compliance with the NERC Reliability Standards.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
1.2. Evidence Retention:
The following evidence retention period(s) identify the period of time an entity is
required to retain specific evidence to demonstrate compliance. For instances
where the evidence retention period specified below is shorter than the time
since the last audit, the Compliance Enforcement Authority may ask an entity to
provide other evidence to show that it was compliant for the full‐time period
since the last audit.
The applicable entity shall keep data or evidence to show compliance as identified
below unless directed by its Compliance Enforcement Authority to retain specific
evidence for a longer period of time as part of an investigation.
The Transmission Owner, Generator Owner, and Distribution Provider shall each
keep data or evidence to show compliance with Requirements R1 through R9, and
Measures M1 through M9 since the last audit, unless directed by its Compliance
Enforcement Authority to retain specific evidence for a longer period of time as
part of an investigation. If a Transmission Owner, Generator Owner or Distribution Provider is found noncompliant, it shall keep information related to the non‐compliance until mitigation is completed and approved, or for the time specified above, whichever
is longer
The Compliance Enforcement Authority shall keep the last audit records and all
requested and submitted subsequent audit records.
1.3. Compliance Monitoring and Enforcement Program
As defined in the NERC Rules of Procedure, “Compliance Monitoring and
Enforcement Program” refers to the identification of the processes that will be
used to evaluate data or information for the purpose of assessing performance or
outcomes with the associated Reliability Standard.
Violation Severity Levels
R # Violation Severity Levels
Lower VSL Moderate VSL High VSL Severe VSL
R1. N/A N/A N/A The RAS‐entity failed to submit the information identified in Attachment 1 to one or more of the Reliability Coordinator(s) in accordance with Requirement R1.
R2. The reviewing Reliability Coordinator performed the review and provided the
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
written feedback in accordance with Requirement R2, but was late by less than or equal to 30‐calendar days.
The reviewing Reliability Coordinator performed the review and provided the written feedback in accordance with Requirement R2, but was late by more than 30‐calendar days but less than or equal to 60‐calendar days.
The reviewing Reliability Coordinator performed the review and provided the written feedback in accordance with Requirement R2, but was late by more than 60‐calendar days but less than or equal to 90‐calendar days.
The reviewing Reliability Coordinator performed the review and provided the written feedback in accordance with Requirement R2, but was late by more than 90‐calendar days.
OR
The reviewing Reliability Coordinator failed to perform the review or provide feedback in accordance with Requirement R2.
VSL Moderate VSL High VSL Severe VSL
R3. The RAS‐entity failed to obtain approval from each reviewing Reliability Coordinator prior to placing a new or functionally modified RAS in service or retiring an existing RAS in accordance with Requirement R3.
R4. The Transmission Planner performed the evaluation in accordance with Requirement R4, but in greater than 60‐full‐calendar months but less than 61‐full calendar months.
The Transmission Planner performed the evaluation in accordance with Requirement R4, but in greater than 61‐full‐calendar months but less than 62‐full calendar months.
The Transmission Planner performed the evaluation in accordance with Requirement R4, but in greater than 62‐full‐calendar months but less than 63‐full calendar
months.
OR
The Transmission Planner performed the evaluation in accordance with Requirement R4, but failed to evaluate one of the Parts 4.1 through 4.4.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
The Transmission Planner performed the evaluation in accordance with Requirement R4, but in greater than 63‐full‐calendar months.
OR
The Transmission Planner failed to perform the evaluation in accordance with Requirement R4.
OR
The Transmission Planner performed the evaluation in accordance with Requirement R4, but failed to evaluate two or more of the Parts 4.1 through 4.4.
OR
The Transmission Planner performed the evaluation in accordance with Requirement R4, but failed to provide the results to one or more of the RAS‐owner(s) and the reviewing Reliability Coordinator(s).
R5. The RAS‐owner performed the analysis in greater than
120‐calendar days, but less than or equal to 130‐calendar days in accordance with Requirement R5.
The RAS‐owner performed the analysis in greater than 130‐calendar days, but less
than or equal to 140‐calendar days in accordance with Requirement R5.
The RAS‐owner performed the analysis in greater than 140‐calendar days, but less
than or equal to 150‐calendar days in accordance with Requirement R5.
OR
The RAS‐owner performed the analysis in accordance with Requirement R5, but
failed to address one of the Parts 5.1 through 5.4.
The RAS‐owner performed the analysis in greater than 150‐calendar days.
OR
The RAS‐owner failed to perform the analysis in accordance with Requirement R5.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
OR
The RAS‐owner performed the analysis in accordance with Requirement R5, but
failed to address two or more of the Parts 5.1 through 5.4.
OR
The RAS‐owner performed the analysis in accordance with Requirement R5, but
failed to provide the results to one or more of the reviewing Reliability Coordinator(s).
R6. The RAS‐owner developed a Corrective Action Plan and submitted it to its reviewing
Reliability Coordinator(s) in accordance with Requirement R6, but was late by less than or equal to 10‐calendar days.
The RAS‐owner developed a Corrective Action Plan and submitted it to its reviewing
Reliability Coordinator(s) in accordance with Requirement R6, but was late by more than 10‐calendar days but less than or equal to 20‐calendar days.
The RAS‐owner developed a Corrective Action Plan and submitted it to its reviewing
Reliability Coordinator(s) in accordance with Requirement R6, but was late by more than 20‐calendar days but less than or equal to 30‐calendar days.
The RAS‐owner developed a Corrective Action Plan and submitted it to its reviewing
Reliability Coordinator(s) in accordance with Requirement R6, but was late by more than 30‐calendar days.
OR
The RAS‐owner developed a Corrective Action Plan and failed to submit it to one or
more of its reviewing Reliability Coordinator(s) in accordance with Requirement R6.
OR
The RAS‐owner failed to develop a Corrective Action Plan in accordance with Requirement R6.
R7. The RAS‐owner implemented a CAP (Part 7.1), but failed to update the
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
CAP (Part 7.2) if actions or timetables changed and failed to notify one or more of the reviewing Reliability Coordinator(s) (Part 7.3), in accordance with
Requirement R7.
N/A N/A The RAS‐owner failed to implement a CAP (Part 7.1) in accordance with
Requirement R7.
R8. The RAS‐owner performed the functional test for a RAS as specified in Requirement
R8, but was less than or equal to 30‐calendar days late.
The RAS‐owner performed the functional test for a RAS as specified in Requirement R8, but was more than 30‐calendar days but less than or equal to 60‐calendar days late.
The RAS‐owner performed the functional test for a RAS as specified in Requirement
R8, but was more than 60‐calendar days but less than or equal to 90‐calendar days
late.
The RAS‐owner performed the functional test for a RAS as specified in Requirement R8, but was more than 90‐calendar days late.
OR
The RAS‐owner failed to perform the functional test for a RAS as specified in Requirement R8.
R9. The Reliability Coordinator updated the RAS database in accordance with Requirement R9, but was late by less than or equal to 30‐calendar days.
The Reliability Coordinator updated the RAS database in accordance with Requirement R9, but was late by more than 30‐calendar days but less than or equal to 60‐calendar days.
The Reliability Coordinator updated the RAS database in accordance with Requirement R9, but was late by more than 60‐calendar days but less than or equal to 90‐calendar days.
The Reliability Coordinator updated the RAS database in accordance with Requirement R9 but was late by more than 90‐calendar days.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
OR
The Reliability Coordinator failed to update the RAS database in accordance with Requirement R9.
D. Regional Variances
None.
E. Associated Documents
Version History
Version Date Action Change Tracking
1 Adopted by NERC Board of Trustees New
Supporting Documentation for RAS Review
The following checklist identifies important Remedial Action Scheme (RAS) information for each new or functionally modified1 RAS that the RAS‐entity shall document and provide to the reviewing Reliability Coordinator(s) (RC) for review. If an item on this list does not apply to a specific RAS, a response of N/A or Not Applicable for that item is appropriate. When a RAS has been previously reviewed, only the proposed modifications to that RAS require review; however, the RAS‐entity must provide a summary of the previously approved functionality. The RC may request additional information on any reliability issue related to the RAS. Additional entities (without decision authority) may be part of the RAS review process at the request of the RC.
I. General
1. Information such as maps, one‐line drawings, substation and schematic drawings that
identify the physical and electrical location of the RAS and related facilities.
2. Functionality of new RAS or proposed functional modifications to existing RAS and
documentation of the pre‐ and post‐modified functionality of the RAS.
3. The Corrective Action Plan (CAP) if RAS modifications are proposed in a CAP.
[Reference NERC Reliability Standard PRC‐012, Requirements R5 and R7]
4. Data to populate the RAS database:
a. RAS name.
b. RAS‐entity and contact information.
c. Expected or actual in‐service date; most recent RC‐approval date (Requirement R3);
most recent evaluation date (Requirement R4); and date of retirement, if applicable.
d. System performance issue or reason for installing the RAS (e.g., thermal overload,
angular instability, poor oscillation damping, voltage instability, under‐ or overvoltage,
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
or slow voltage recovery).
e. Description of the contingencies or System conditions for which the RAS was
designed (i.e., initiating conditions).
f. Action(s) to be taken by the RAS.
g. Any additional explanation relevant to high‐level understanding of the RAS.
1 Functionally Modified: Any modification to a RAS beyond the replacement of components that preserve the original
functionality is a functional modification.
Attachments
II. Functional Description and Transmission Planning Information
1. Contingencies and System conditions that the RAS is intended to remedy.
[Reference NERC Reliability Standards PRC‐012, R1.2 and PRC‐013, R1.1]
2. The action(s) to be taken by the RAS in response to disturbance conditions.
[Reference NERC Reliability Standards PRC‐012, R1.2 and PRC‐013, R1.2]
3. A summary of technical studies, if applicable, demonstrating that the proposed RAS
actions satisfy System performance objectives for the scope of System events and
conditions that the RAS is intended to remedy. The technical studies summary shall also
include information such as the study year(s), System conditions, and Contingencies
analyzed on which the RAS design is based, and the date those technical studies were
performed. [Reference NERC Reliability Standard PRC‐014, R3.2]
4. Information regarding any future System plans that will impact the RAS.
[Reference NERC Reliability Standard PRC‐014, R3.2]
Documentation showing that the possible inadvertent operation of the RAS resulting
from any single RAS component malfunction satisfies all of the following:
[Reference NERC Reliability Standard PRC‐012, R1.4]
a. The BES shall remain stable.
b. Cascading shall not occur.
c. Applicable Facility Ratings shall not be exceeded.
d. BES voltages shall be within post‐Contingency voltage limits and post‐Contingency
voltage deviation limits as established by the Transmission Planner and the Planning
Coordinator.
e. Transient voltage responses shall be within acceptable limits as established by the
Transmission Planner and the Planning Coordinator.
5. An evaluation indicating that the RAS settings and operation avoid adverse interactions
with other RAS, and protection and control systems.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
[Reference NERC Reliability Standards PRC‐012, R1.5 and PRC‐014, R3.4]
6. Identification of other affected RCs.
III. Implementation
1. Documentation describing the applicable equipment used for detection,
telecommunications, transfer trip, logic processing, and monitoring.
2. Information on detection logic and settings/parameters that control the operation of
the RAS. [Reference NERC Reliability Standards PRC‐012, R1.2 and PRC‐013, R1.3]
3. Documentation showing that any multifunction device used to perform RAS function(s),
in addition to other functions such as protective relaying or SCADA, does not
compromise the reliability of the RAS when the device is not in service or is being
maintained.
Attachments
4. Documentation showing that a single component failure in the RAS, when the RAS is
intended to operate, does not prevent the BES from meeting the same performance
requirements (defined in Reliability Standard TPL‐001‐4 or its successor) as those
required for the events and conditions for which the RAS is designed. The
documentation should describe or illustrate how the design achieves this objective.
[Reference NERC Reliability Standard PRC‐012, R1.3]
5. Documentation describing the functional testing process.
IV. RAS Retirement
The following checklist identifies RAS information that the RAS‐entity shall document and
provide to each reviewing RC.
1. Information necessary to ensure that the RC is able to understand the physical and
electrical location of the RAS and related facilities.
2. A summary of applicable technical studies and technical justifications upon which the
decision to retire the RAS is based.
3. Anticipated date of RAS retirement.
Reliability Coordinator RAS Review Checklist
The following checklist identifies reliability‐related considerations for the Reliability Coordinator (RC) to review and verify for each new or functionally modified2 Remedial Action Scheme (RAS).
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
The RC review is not limited to the checklist items and the RC may request additional
information on any reliability issue related to the RAS.
I. Design
1. The RAS actions satisfy performance objectives for the scope of events and conditions
that the RAS is intended to mitigate.
2. The RAS arming conditions, if applicable, are appropriate to its System performance
objectives.
3. The RAS avoids adverse interactions with other RAS, and protection and control
systems.
4. The effects of RAS incorrect operation, including inadvertent operation and failure to
operate (if non‐operation for RAS single component failure is acceptable), have been
identified.
5. The possible inadvertent operation of the RAS resulting from any single RAS component malfunction satisfies all of the following:
a. The BES shall remain stable.
b. Cascading shall not occur.
c. Applicable Facility Ratings shall not be exceeded.
d. BES voltages shall be within post‐Contingency voltage limits and post‐Contingency
voltage deviation limits as established by the Transmission Planner and the Planning
Coordinator.
e. Transient voltage responses shall be within acceptable limits as established by the
Transmission Planner and the Planning Coordinator.
6. The effects of future BES modifications on the design and operation of the RAS have
been identified, where applicable.
II. Implementation
1. The implementation of RAS logic appropriately correlates desired actions (outputs) with
events and conditions (inputs).
2. The timing of RAS action(s) is appropriate to its BES performance objectives.
2 Functionally Modified:
Any modification to a RAS beyond the replacement of components that preserve the original functionality is a
functional modification.
3. A single component failure in a RAS does not prevent the BES from meeting the same
performance requirements as those required for the events and conditions for which
the RAS is designed.
4. The RAS design facilitates periodic testing and maintenance.
5. The mechanism or procedure by which the RAS is armed is clearly described, and is
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
appropriate for reliable arming and operation of the RAS for the conditions and events
for which it is designed to operate.
III. RAS Retirement
RAS retirement reviews should assure that there is adequate justification for why a RAS is no longer needed.
Database Information
1. RAS name.
2. RAS‐entity and contact information.
3. Expected or actual in‐service date; most recent RC‐approval date (Requirement R3);
most recent evaluation date (Requirement R4); and date of retirement, if applicable.
4. System performance issue or reason for installing the RAS (e.g., thermal overload,
angular instability, poor oscillation damping, voltage instability, under‐ or over‐voltage,
or slow voltage recovery).
5. Description of the Contingencies or System conditions for which the RAS was designed
(i.e., initiating conditions).
6. Action(s) to be taken by the RAS.
7. Any additional explanation relevant to high‐level understanding of the RAS.
Supplemental Material
Technical Justifications for Requirements
Applicability
4.1.4 RAS‐entity
The purpose of the RAS‐entity is to be the single information conduit with each reviewing Reliability Coordinator (RC) for all RAS‐owners for each RAS. The RAS‐entity needs to coordinate all review materials and any presentations. If all of the RAS equipment has a single owner, then the RAS‐entity is the same as the RAS‐owner and that owner speaks for itself. If the RAS equipment has more than one owner, then each separate RAS equipment owner is a RAS‐owner. The RAS‐entity will always be one of these RAS‐owners. A RAS‐entity will be selected by all RAS‐owners and, traditionally, has usually been the owner of the RAS controller and a Transmission Owner. If a specific
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
RAS‐entity is not identified by the RAS‐owners, the RC will assign that function to the RAS‐owner who provides the review material to them.
The RAS‐owner(s); i.e., Transmission Owner(s), Generator Owner(s), or Distribution Provider(s) who are not the RAS‐entity still have responsibilities as assigned in other NERC Reliability Standards, such as equipment maintenance. In addition, when RAS modifications are needed, each RAS‐owner of RAS equipment that must be modified must accept the specific responsibilities assigned to them as described in the necessary Corrective Action Plan (CAP), or otherwise as described in the revised Attachment 1.
Requirement R1
Each RAS is unique and its action(s) can have a significant impact on the reliability and integrity of the Bulk Electric System (BES); therefore, a review of a proposed new RAS or an existing RAS proposed for functional modification, or retirement (removal from service) must be completed prior to implementation.
Any modification to RAS hardware beyond the substitution of components that merely
preserve the original functionality is a functional modification. Any change in RAS logic such as new inputs or outputs, or any other modification that affects overall RAS functionality, or redundancy level as documented in the original submission for review are functional modifications. RAS modifications identified by a CAP pursuant to Requirement R6 beyond the substitution of components that merely preserve the original functionality are functional modifications. RAS removal is essentially a form of RAS functional modification. Any RAS proposed for removal needs to be evaluated under the RAS Retirement section of the
Attachment 1 checklist.
To facilitate a review that promotes reliability, the RAS‐entity must provide the reviewer with sufficient details of the RAS design, function, and operation. This data and supporting documentation are identified in Attachment 1 of this standard, and Requirement R1 mandates that the RAS‐entity provide them to the reviewing Reliability Coordinator (RC). The RC that coordinates the area where the RAS is located is responsible for the review. In cases where a RAS crosses multiple RC Area boundaries, each affected RC is responsible for conducting either individual reviews or a coordinated review.
Requirement R1 does not specify how far in advance of implementation the RAS‐entity must provide Attachment 1 data to the reviewing RC. The information will need to be submitted early enough to allow RC review in the allotted time pursuant to Requirement R2, including resolution of any issues that might be identified, in order to obtain approval
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
of the reviewing RC. Expeditious submittal of this information is in the interest of each RAS‐owner to effect a timely implementation.
Requirement R2
Requirement R2 mandates that the RC perform reviews of all proposed new RAS and existing RAS proposed for functional modification, or retirement (removal from service) in its RC Area.
RAS are unique and customized assemblages of protection and control equipment. As such, they have a potential to introduce reliability risks to the BES, if not carefully planned, designed, and installed. A RAS may be installed to address a reliability issue, or achieve an economic or operational advantage, and could introduce reliability risks that might not be apparent to a RAS‐owner(s). An independent review by a multi‐disciplinary panel of subject matter experts with planning, operations, protection, elecommunications, and equipment expertise is an effective means of identifying risks and recommending RAS modifications when necessary.
The RC is the functional entity best suited to perform the RAS reviews because it has the
widest‐area reliability perspective of all functional entities and an awareness of reliability issues in neighboring RC Areas. This Wide Area purview provides continuity in the review process and facilitates the evaluation of interactions among separate RAS as well as interactions among the RAS and other protection and control systems. The selection of the RC also minimizes the possibility of a “conflict of interest” that could exist because of business relationships among the RAS‐entity, Planning Coordinator (PC), Transmission Planner (TP), or other entities that are likely to be involved in the planning or implementation of a RAS. The RC may request assistance in RAS reviews from other parties such as the PC(s) or regional technical groups (e.g., Regional Entities); however, the RC retains responsibility for compliance with the requirement.
Attachment 2 of this standard is a checklist for assisting the RC in identifying design and
implementation aspects of a RAS, and for facilitating consistent reviews of each submitted RAS for review. The time frame of four‐full‐calendar months is consistent with current utility practice; however, flexibility is provided by allowing the parties to negotiate a different schedule for the review. Note, an RC may need to include this task in its reliability plan(s) for the NERC Region(s) in which it is located.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
Requirement R3
Requirement R3 mandates that the RAS‐entity address all issues identified by the reviewing RC during the RAS review, and obtain approval from the reviewing RC that the RAS implementation can proceed. The review by the RC is intended to identify reliability issues that must be resolved before the RAS can be put in service. Examples of reliability issues include a lack of dependability, security, or coordination.
Dependability is a component of reliability and is the measure of certainty of a device to
operate when required. If a RAS is installed to meet performance requirements of NERC
Reliability Standards, a failure of the RAS to operate when intended would put the System at risk of violating NERC Reliability Standards if specified Contingency(ies) or System conditions occur.
This risk is mitigated by designing the RAS so that it will accomplish the intended purpose while experiencing a single RAS component failure. This is often accomplished through redundancy. Other strategies for providing dependability include “over‐tripping” load or generation, or alternative automatic backup schemes.
Security is a component of reliability and is the measure of certainty of a device to not operate inadvertently. False or inadvertent operation of a RAS results in taking a programmed action without the appropriate arming conditions, occurrence of specified Contingency(ies), or System conditions expected to trigger the RAS action. Typical RAS actions include shedding load or generation or re‐configuring the System. Such actions, if inadvertently taken, are undesirable and may put the System in a less secure state. Worst case impacts from inadvertent operation often occur if all programmed RAS actions occur. If the System performance still satisfies PRC‐012‐2 Requirement R4, Part 4.3, no additional mitigation is required. Security enhancements to the RAS design, such as voting schemes, are acceptable mitigations against inadvertent operations.
Any reliability issue identified during the review must be resolved before implementing the RAS to avoid placing the System at unacceptable risk. The RAS‐entity (and any other RAS‐owner) or the reviewing RC(s) may have alternative ideas or methods available to resolve the issue(s). In either case, the concern needs to be resolved in deference to reliability, and the RC has the final decision.
A specific time period for the RAS‐entity to respond to the RC(s) review is not necessary
because an expeditious response is in the interest of each RAS‐owner to effect a timely
implementation.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
Requirement R4
Requirement R4 mandates that an evaluation of each RAS be performed at least once every 60‐full‐calendar months. The purpose of a periodic RAS evaluation is to verify the continued effectiveness and coordination of the RAS, as well as to verify that requirements for BES performance following inadvertent RAS operation and single component failure continue to be satisfied. A periodic evaluation is required because changes in system topology or operating conditions that have occurred since the previous RAS evaluation (or initial review) may change the effectiveness of a RAS or the way it interacts with and impacts the BES.
A period of sixty‐full‐calendar months was selected as the maximum time frame between
evaluations based on similar requirements in NERC Reliability Standards PRC‐006, PRC‐010, and PRC‐014. The RAS evaluation should be performed sooner if it is determined that material changes to System topology or System operating conditions that could potentially impact the effectiveness or coordination of the RAS have occurred since the previous RAS evaluation or will occur before the next scheduled evaluation.
The periodic RAS evaluation will lead to one of the following outcomes:
1) affirmation that the existing RAS is effective; 2) identification of changes
needed to the existing RAS; or 3) justification for RAS retirement.
The items required to be addressed in the evaluations (Requirement R4, Parts 4.1 through 4.4) are planning analyses that involve modeling of the interconnected transmission system to assess BES performance; consequently, the TP is the functional entity best suited to perform the analyses. To promote reliability, the TP is required to provide the RAS‐owner(s) and the reviewing RC(s) with the results of each evaluation.
The intent of Requirement R4, Part 4.3 is to require that the possible inadvertent operation of the RAS, caused by the malfunction of a single component of the RAS, meet the same System performance requirements as those required for the Contingency(ies) or System conditions for which it is designed. If the RAS is designed to meet one of the planning events (P0‐P7) in TPL‐001‐4, the possible inadvertent operation of the RAS must meet the same performance requirements listed in the standard for that planning event. The requirement clarifies that the inadvertent operation to be considered is only that caused by the malfunction of a single RAS component. This allows features to be designed into the RAS to improve security, such that inadvertent operation due to malfunction of a single component is prevented or else the RAS inadvertent operation satisfies Requirement R4, Part 4.3.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
The intent of Requirement R4, Part 4.3 is also to require that the possible inadvertent operation of the RAS installed for an extreme event in TPL‐001‐4 or for some other Contingency or System conditions not defined in TPL‐001‐4 (therefore without performance requirements), meet the minimum System performance requirements of Category P7 in Table 1 of NERC Reliability Standard TPL‐001‐4. However, instead of referring to the TPL standard, the requirement lists the System performance requirements that a potential inadvertent operation must satisfy.The performance requirements listed (Requirement R4, Parts 4.3.1 – 4.3.5) are the ones that are common to all planning events P0‐P7 listed in TPL‐001‐4.
With reference to Requirement 4, Part 4.3, note that the only differences in performance
requirements among the TPL P0‐P7 events (not common to all of them) concern Non‐
Consequential Load Loss and interruption of Firm Transmission Service. Performance
requirements in these areas are not relevant. A RAS is only allowed to drop non‐consequential load or interrupt Firm Transmission Service can do that only if that action is allowed for the Contingency for which it is designed. Therefore, the inadvertent operation should automatically meet Non‐Consequential Load Loss or interrupting Firm Transmission Service performance requirements for the Contingency(ies) for which it was designed.
Part 4.4 requires that a single component failure in the RAS, when the RAS is intended to
operate, does not prevent the BES from meeting the same performance requirements (defined in Reliability Standard TPL‐001‐4 or its successor) as those required for the events and conditions for which the RAS is designed. This analysis is needed to ensure that changing System conditions do not result in the single component failure requirement not being met.
Requirements for inadvertent RAS operation (Requirement R4, Part 4.3) and single component failure (Requirement R4, Part 4.4) are reviewed by the reviewing RC(s) before a new or functionally modified RAS is placed in service, and are typically satisfied by specific design considerations. Although the scope of the periodic evaluation does not include a new design review, it is possible that a design which previously satisfied requirements for inadvertent RAS operation and single component failure may fail to satisfy these requirements at a later point in time, and must be evaluated with respect to the current System. For example, if the actions of a
particular RAS include tripping load, System changes could occur over time that impact the amount of load originally tripped by a particular RAS output. These changes could result in inadvertent activation of that output, therefore, tripping too much load and result in violations of Facility Ratings. Alternatively, the RAS might be designed to trip more
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
load than necessary (i.e., “over trip”) in order to satisfy single‐component‐failure requirements. System changes could result in too little load being tripped at affected locations and result in unacceptable BES performance if one of the loads failed to trip.
Requirement R5
The correct operation of a RAS is important to maintain the reliability and integrity of the BES. Any incorrect operation of a RAS indicates the RAS effectiveness and/or coordination may have been compromised. Therefore, all operations of a RAS and failures of a RAS to operate when expected must be analyzed to verify that the RAS operation was consistent with its intended functionality and design.
A RAS operational performance analysis is intended to: (1) verify RAS operation is consistent with implemented design; or (2) identify RAS performance deficiency(ies) that manifested in the incorrect RAS operation or failure of RAS to operate when expected.
The 120‐calendar day time frame for the completion of RAS operational performance analysis aligns with the time frame established in Requirement R1 from PRC‐004‐4 regarding the investigation of a Protection System Misoperation. To promote reliability, the RAS‐owner(s) is required to provide the results of RAS operational performance analyses to its reviewing RC(s).
The RAS‐owner(s) may need to collaborate with their associated TP to comprehensively analyze RAS operational performance. This is because a RAS operational performance analysis involves verifying that the RAS operation triggers and responds (Parts 5.1, 5.2) and that the resulting BES response (Parts 5.3, 5.4) is consistent with the intended functionality and design of the RAS.
Requirement R6
Deficiencies identified either in the periodic RAS evaluation conducted by the TP in
Requirement R4, or in the analysis conducted by the RAS‐owner(s) pursuant to Requirement R5, are likely to pose a reliability risk to the BES. To mitigate this reliability risk, Requirement R6 mandates that each RAS‐owner develop a CAP that establishes the mitigation actions and timetable to address the deficiency. If the CAP requires that a functional change be made to a RAS, Attachment 1 information must be submitted to the reviewing RC(s) prior to placing RAS modifications in service per Requirement R1.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
Depending on the complexity of the issues, development of a CAP may require study,
engineering, or consulting work. A timeframe of six‐full‐calendar months is allotted to allow enough time for RAS‐owner collaboration on the CAP development, while ensuring that deficiencies are addressed in a reasonable time. A RAS deficiency may require the RC or Transmission Operator to impose operating restrictions so the System can operate in a reliable way until the RAS deficiency is resolved. Such operating restrictions will incent the RAS‐owner to resolve the issue as quickly as possible.
A CAP documents a RAS performance deficiency, the actions to correct the deficiency with identified tasks, and the time frame for completion.
The following are example situations of when a CAP is required:
A determination after a RAS operation/non‐operation investigation that the RAS did not meet performance expectations. The RAS did not operate as designed.
Periodic planning assessment reveals RAS changes are necessary to correct performance or coordination issues.
Equipment failures.
Requirement R7
Implementation of a CAP ensures that RAS deficiencies are corrected by following a
documented timetable of identified actions. If necessary, the CAP can be modified to account for adjustments to the actions or scheduled timetable of activities. Operating restrictions imposed by the RC also incents RAS‐owners to mitigate the issues and provide assurance that implementation is completed in a timely manner.
Requirement R8
The reliability objective of Requirement R8 is to test the non‐Protection System components of a RAS (controllers such as programmable logic controllers (PLCs)) and to verify the overall performance of the RAS through functional testing. Functional tests validate RAS operation by ensuring System states are detected and processed, and that actions taken by the controls are correct and within the expected time using the in‐service settings and logic. Functional testing is aimed at assuring overall RAS performance and not the component focused testing contained in the PRC‐005 maintenance standard.
Since the functional test operates the RAS under controlled conditions with known System states and expected results, testing and analysis can be performed without impact to the BES and should align with expected results. The RAS‐owner is in the best position to determine the testing procedure and schedule due to their overall knowledge of the RAS design, installation, and functionality. Periodic testing provides the RAS‐owner
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
assurance that latent failures may be identified and also promotes identification of changes in the System that may have introduced latent failures.
While the six‐calendar‐year functional testing interval is greater than the annual or bi‐annual periodic testing performed in some NERC Regions, the drafting team selected it because it is consistent with some of the maintenance intervals of various Protection System and Automatic Reclosing components established in PRC‐005. Consequently, this interval provides entities the opportunity to design their RAS functional testing programs such that it coincides with the testing of any associated PRC‐005 components. The six‐calendar‐year interval is a balance between the resources required to perform the testing and the potential reliability impacts to the BES created by undiscovered latent failures that could cause an incorrect operation of the RAS.
Functional testing is not synonymous with end‐to‐end testing. End‐to‐end testing is acceptable but it may not feasible for many RAS. When end‐to‐end testing is not possible, a RAS‐owner may use a segmented functional testing approach. The segments can be tested individually negating the need for complex maintenance schedules. In addition, actual RAS operation(s) can be used to fulfill the functional testing requirement. If a RAS does not operate in its entirety during a System event or System conditions do not allow an end‐to‐end system test—the, the segmented approach should be used to fulfill this Requirement. Functional testing includes the testing of all RAS inputs used for detection, arming, operating, and data collection. Functional testing also includes the processing by the logic and infrastructure of a RAS as well as the action initiation by RAS outputs to address the System condition(s) for which the RAS is designed. All
segments and components of a RAS must be tested or have proven operations within a sixcalendar‐year interval to demonstrate compliance with the Requirement.
As an example, consider a RAS implemented with one PLC that senses System conditions such as loading and line status from many locations. At one of these locations, a line protective relay (a component of a Protection System and included in the Protection System Maintenance Program (PSMP) of a RAS‐owner) receives commands from the RAS PLC and sends data over non‐Protection System communications infrastructure to operate a breaker. A functional test would send signals of simulated System conditions to the PLC to initiate an operate command to the protective relay, thus operating its associated breaker. This action verifies RAS action, verifies PLC control logic, and verifies RAS communications from PLC to relay. To complete this portion of a functional test, application of external testing signals to the protective relay, verified at the PLC are necessary to confirm full functioning of the RAS segment being tested.
This example describes a test for one segment of the RAS, the remaining segments would also require testing.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
IEEE C37.233, “IEEE Guide for Power System Protection Testing,” 2009 section 8 (particularly 8.3‐8.5), provides an overview of functional testing. The following opens section 8.3: Proper implementation requires a well‐defined and coordinated test plan for performance evaluation of the overall system during agreed maintenance intervals. The maintenance test plan, also referred to as functional system testing, should include inputs, outputs, communication, logic, and throughput timing tests. The functional tests are generally not component‐level testing, rather overall system testing. Some of the input tests may need to be done ahead of overall system testing to the extent that the tests affect the overall performance.
The test coordinator or coordinators need to have full knowledge of the intent of the scheme, isolation points, simulation scenarios, and restoration to normal procedures.
The concept is to validate the overall performance of the scheme, including the logic where applicable, to validate the overall throughput times against system modeling for different types of contingencies, and to verify scheme performance as well as the inputs and outputs.
If a RAS passes a functional test, it is not necessary to provide that specific information to the RC because that is the expected result and requires no further action. If a segment of a RAS fails a functional test, the status of that degraded RAS is required to be reported (in Real‐time) to the Transmission Operator via PRC‐001, Requirement R6, then to the RC via TOP‐001‐2, Requirement R5. Consequently, it is not necessary to include a similar requirement in this standard.
Requirement R9
The RAS database required to be maintained by the RC in Requirement R9 ensures information regarding existing RAS is available to entities with a potential reliability need. Attachment 3 contains the minimum information that is required to be included about each RAS listed in the database. Additional information can be requested by the RC.
The information provided is sufficient for an entity with a reliability need to evaluate whether the RAS can impact its System. For example, a RAS performing generation rejection to mitigate an overload on a transmission line may cause a power flow change within an adjacent entity area. This entity should be able to evaluate the risk that a RAS poses to its System from the high‐level information provided in the RAS database.
The RAS database does not need to list detailed settings or modeling information, but the
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
description of the System performance issues, System conditions, and the intended corrective actions must be included. If additional details about the RAS operation are required, the entity may obtain the contact information of the RAS‐entity from the RC.
The following diagrams depict the process flow of the PRC‐012‐2 requirements.
Technical Justifications for Attachment 1 Content
Supporting Documentation for RAS Review
To perform an adequate review of the expected reliability implications of a Remedial Action Scheme (RAS), it is necessary for the RAS‐owner(s) to provide a detailed list of information describing the RAS to the designated RAS‐entity. If there are multiple owners of the RAS, information may be needed from all owners, but a single RAS‐owner (designated as the RASentity) is assigned the responsibility of compiling the RAS data and presenting it to the reviewing RC(s). Other RAS‐owners may participate in the review, if they choose.
The necessary data ranges from a general overview of the RAS to summarized results of
transmission planning studies, to information about hardware used to implement the RAS.
Coordination between the RAS and other RAS and protection and control systems will be
examined for possible adverse interactions. This review can include wide‐ranging electrical design issues involving the specific hardware, logic, telecommunications, and other relevant equipment and controls that make up the RAS.
Attachment 1
The following checklist identifies important RAS information for each new or functionally modified3 RAS that the RAS‐entity shall document and provide to the RC for review pursuant to Requirement R1. When a RAS has been previously reviewed, only the proposed modifications to that RAS require review; however, it will be helpful to each reviewing RC if the RAS‐entity provides a summary of the previously approved RAS functionality.
I. General
1. Information such as maps, one‐line drawings, substation and schematic drawings that
identify the physical and electrical location of the RAS and related facilities.
Provide a description of the RAS to give an overall understanding of the functionality
and a map showing the location of the RAS. Identify other protection and control
systems requiring coordination with the RAS. See RAS Design below for additional
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
information. Provide a single‐line drawing(s) showing all sites involved. The drawing(s) should provide sufficient information to allow the RC review team to assess design reliability, and should include information such as the bus arrangement, circuit breakers, the associated switches, etc. For each site, indicate whether detection, logic, action, or a
combination of these is present.
2. Functionality of new RAS or proposed functional modifications to existing RAS and
documentation of the pre‐ and post‐modified functionality of the RAS.
3Functionally Modified: Any modification to a RAS beyond the replacement of components that preserve the original functionality is a functional modification.
3. The Corrective Action Plan (CAP) if RAS modifications are proposed in a CAP.
[Reference NERC Reliability Standard PRC‐012‐2, Requirements R5 and R7]
Provide a description of any functional modifications to a RAS that are part of a CAP that
are proposed to address performance deficiency(ies) identified in the periodic
evaluation pursuant to Requirement R4, or the analysis of an actual RAS operation
pursuant to Requirement R5. A copy of the most recent CAP must be submitted in
addition to the other data specified in Attachment 1.
4. Initial data to populate the RAS database.
a. RAS name
b. RAS‐entity and contact information
c. Expected or actual in‐service date; most recent (Requirement R3) RC‐approval date;
most recent 60‐full‐calendar‐month (Requirement R4) evaluation date; and, date of
retirement, if applicable
d. System performance issue or reason for installing the RAS (e.g., thermal overload,
angular instability, poor oscillation damping, voltage instability, under‐/over‐voltage,
slow voltage recovery)
e. Description of the contingencies or System conditions for which the RAS was
designed (initiating conditions)
f. Corrective action taken by the RAS
g. Any additional explanation relevant to high level understanding of the RAS
Note: This is the same information as is identified in Attachment 3. Supplying the
data at this point in the review process ensures a more complete review and
minimizes any administrative burden on the reviewing RC(s).
II. Functional Description and Transmission Planning Information
1. Contingencies and system conditions that the RAS is intended to remedy.
[Reference NERC Reliability Standards PRC‐012, R1.2 and PRC‐013, R1.1]
a. The System conditions that would result if no RAS action occurred should be
identified.
b. Include a description of the System conditions that should arm the RAS so as to be
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
ready to take action upon subsequent occurrence of the critical system
contingencies or other operating conditions when RAS action is intended to occur. If
no arming conditions are required, this should also be stated.
c. Event‐based RAS are triggered by specific contingencies that initiate mitigating
action. Condition‐based RAS may also be initiated by specific contingencies, but
specific Contingencies are not always required. These triggering Contingencies
and/or conditions should be identified.
2. The actions to be taken by the RAS in response to disturbance conditions.
[Reference NERC Reliability Standards PRC‐012, R1.2 and PRC‐013, R1.2]
Mitigating actions are designed to result in acceptable System performance. These
actions should be identified, including any time constraints and/or “backup” mitigating
measures that may be required in case of a single RAS component failure.
3. A summary of technical studies, if applicable, demonstrating that the proposed RAS
actions satisfy System performance objectives for the scope of System events and
conditions that the RAS is intended to remedy. The technical studies summary shall also
include information such as the study year(s), system conditions, and contingencies
analyzed on which the RAS design is based, and when those technical studies were
performed. [Reference NEC Reliability Standard PRC‐014, R3.2]
Review the scheme purpose and impact to ensure it is (still) necessary, serves the
intended purposes, and meets current performance requirements. While copies of the
full, detailed studies may not be necessary, any abbreviated descriptions of the studies
must be detailed enough to allow the reviewing RC(s) to be convinced of the need for
the scheme and the results of RAS‐related operations.
4. Information regarding any future system plans that will impact the RAS.
[Reference NERC Reliability Standard PRC‐014, R3.2]
The RC’s other responsibilities under the NERC Reliability Standards focus on the
Operating Horizon, rather than the Planning Horizon. As such, the RC is less likely to be
aware of any longer range plans that may have an impact on the proposed RAS. Such
knowledge of future Plans is helpful to provide perspective on the capabilities of the
RAS.
5. Documentation showing that the possible inadvertent operation of the RAS resulting
from any single RAS component malfunction satisfies all of the following:
[Reference NERC Reliability Standard PRC‐012, R1.4]
a. The BES shall remain stable.
b. Cascading shall not occur.
c. Applicable Facility Ratings shall not be exceeded.
d. BES voltages shall be within post‐Contingency voltage limits and post‐Contingency
voltage deviation limits as established by the Transmission Planner and the Planning
Coordinator.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
e. Transient voltage responses shall be within acceptable limits as established by the
Transmission Planner and the Planning Coordinator.
6. An evaluation indicating that the RAS settings and operation avoids adverse interactions
with other RAS, and protection and control systems.
[Reference NERC Reliability Standards PRC‐012, R1.5 and PRC‐014, R3.4]
RAS are complex schemes that may take action such as tripping load or generation or reconfiguring the system. Many RAS depend on sensing specific System configurations to determine whether they need to arm or take actions. An examples of an adverse
interaction: A RAS that reconfigures the System also changes the available fault duty,
which can affect distance relay overcurrent (“fault detector”) supervision and ground
overcurrent protection coordination.
7. Identification of other affected RCs.
This information is needed to aid in information exchange among all affected entities
and coordination of the RAS with other RAS and protection and control systems.
III. Implementation
1. Documentation describing the applicable equipment used for detection,
telecommunications, transfer trip, logic processing, and monitoring.
Detection
Detection and initiating devices, whether for arming or triggering action, should be designed to be secure. Several types of devices have been commonly used as disturbance, condition, or status detectors:
Line open status (event detectors),
Protective relay inputs and outputs (event and parameter detectors),
Transducer and IED (analog) inputs (parameter and response detectors),
Rate of change (parameter and response detectors).
Telecommunications Channels and Transfer Trip Equipment
Telecommunications channels used for sending and receiving RAS information between
sites and/or transfer trip devices should meet at least the same criteria as other relaying
protection communication channels. Discuss performance of any non‐deterministic
communication systems used (such as Ethernet). The scheme logic should be designed so that loss of the channel, noise, or other channel or equipment failure will not result in a false operation of the scheme.
It is highly desirable that the channel equipment and communications media (power line
carrier, microwave, optical fiber, etc.) be owned and maintained by the RAS‐owner, or
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
perhaps leased from another entity familiar with the necessary reliability requirements. All channel equipment should be monitored and alarmed to the dispatch center so that timely diagnostic and repair action shall take place upon failure. Publicly switched telephone networks are generally an undesirable option.
Communication channels should be well labeled or identified so that the personnel working on the channel can readily identify the proper circuit. Channels between entities should be identified with a common name at all terminals. Transfer trip equipment, when separate from other RAS equipment, should be monitored and labeled similarly to the channel equipment.
Logic Processing
All RAS require some form of logic processing to determine the action to take when the
scheme is triggered. Required actions are always scheme dependent. Different actions may be required at different arming levels or for different contingencies. Scheme logic may be achievable by something as simple as wiring a few auxiliary relay contacts or by much more complex logic processing.
Platforms that have been used reliably and successfully include PLCs in various forms,
personal computers (PCs), microprocessor protective relays, remote terminal units (RTUs), and logic processors. Single‐function relays have been used historically to implement RAS, but this approach is now less common except for very simple new RAS or minor additions to existing RAS.
Monitoring by SCADA/EMS should include at least
Whether the scheme is in‐service or out of service.
For RAS that are armed manually, the arming status may be the same as whether
the RAS is in‐service or out of service.
For RAS that are armed automatically, these two states are independent because a
RAS that has been placed in service may be armed or unarmed based on whether
the automatic arming criteria have been met.
The current operational state of the scheme (available or not).
In cases where the RAS requires single‐component failure performance (redundancy),
the minimal status indications should be provided separately for each system.
The minimum status is generally sufficient for operational purposes; however,
where possible it may be useful to provide additional information regarding partial
failures or the status of critical components to allow the RAS‐owner to more
efficiently troubleshoot a reported failure. Whether this capability exists will depend
in part on the design and vintage of equipment used in the RAS. While all schemes
should provide the minimum level of monitoring, new schemes should be designed
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
with the objective of providing monitoring at least similar to what is provided for
microprocessor‐based Protection Systems.
2. Information on detection logic and settings/parameters that control the operation of
the RAS. [Reference NERC Reliability Standards PRC‐012, R1.2 and PRC‐013, R1.3]
Several methods to determine line or other equipment status are in common use, often
in combination:
a. Auxiliary switch contacts from circuit breakers and disconnect switches (52a/b,
89a/b)—the most common status monitor; “a” contacts exactly emulate actual
breaker status, while “b” contacts are opposite to the status of the breaker;
b. Undercurrent detection—a low level indicates an open condition, including at the far
end of a line; pickup is typically slightly above the total line‐charging current;
c. Breaker trip coil current monitoring—typically used when high‐speed RAS response
is required, but usually in combination with auxiliary switch contacts and/or other
detection because the trip coil current ceases when the breaker opens; and
d. Other detectors such as angle, voltage, power, frequency, rate of change of these,
out of step, etc.—very dependent on specific scheme requirements, but some forms
may substitute for or enhance current monitoring detection.
Both RAS arming and action triggers often require monitoring of analog quantities such
as power, current, and voltage at one or more locations and are set to detect a specific
level of the pertinent quantity. These monitors may be relays, meters, transducers, or
other devices
3. Documentation showing that any multifunction device used to perform RAS function(s),
in addition to other functions such as protective relaying or SCADA, does not
compromise the reliability of the RAS when the device is not in service or is being
maintained.
In this context, a multifunction device (e.g., microprocessor‐based relay) is a single
component that is used to perform the function of a RAS in addition to protective
relaying and/or SCADA simultaneously. It is important that other applications in the
multifunction device do not compromise the functionality of the RAS when the device is
in service or when it is being maintained. The following list outlines considerations when
the RAS function is applied in the same microprocessor‐based relay as equipment
protection functions:
a. Describe how the multifunction device is applied in the RAS.
b. Show the general arrangement and describe how the multi‐function device is
labeled in the design and application, so as to identify the RAS and other device
functions.
c. Describe the procedures used to isolate the RAS function from other functions in the
device.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
d. Describe the procedures used when each multifunction device is removed from
service and whether coordination with other protection schemes is required.
e. Describe how each multifunction device is tested, both for commissioning and
during periodic maintenance testing, with regard to each function of the device.
f. Describe how overall periodic RAS functional and throughput tests are performed if
multifunction devices are used for both local protection and RAS.
g. Describe how upgrades to the multifunction device, such as firmware upgrades, are
accomplished. How is the RAS function taken into consideration?
Other devices that are usually not considered multifunction devices such as auxiliary
relays, control switches, and instrument transformers may serve multiple purposes such
as protection and RAS. Similar concerns apply for these applications as noted above.
4. Documentation showing that a single‐component failure in a RAS, when the RAS is
intended to operate, does not prevent the BES from meeting the same performance
requirements (defined in Reliability Standard TPL‐001‐4 or its successor) as those
required for the events and conditions for which the RAS is designed. The
documentation should describe or illustrate how the implementation design achieves
this objective. [Reference NERC Reliability Standard PRC‐012, R1.3]
RAS automatic arming, if applicable, is vital to RAS and System performance and is
therefore included in this requirement.
Acceptable methods to achieve this objective include the following:
a. Providing redundancy of RAS components listed below:
i. Protective or auxiliary relays used by the RAS.
ii. Communications systems necessary for correct operation of the RAS.
iii. Sensing devices used to measure electrical quantities used by the RAS.
iv. Station dc supply associated with RAS functions.
v. Control circuitry associated with RAS functions through the trip coil(s) of the
circuit breakers or other interrupting devices.
vi. Computers or programmable logic devices used to analyze information and
provide RAS operational output.
b. Arming more load or generation than necessary such that failure of the RAS to drop
a portion of load or generation would not be an issue, if tripping the total armed
amount of load or generation does not cause other adverse impacts to reliability.
c. Using alternative automatic actions to back up failures of single RAS components.
d. Manual backup operations, using planned System adjustments such as Transmission
configuration changes and re‐dispatch of generation, if such adjustments are
executable within the time duration applicable to the Facility Ratings.
5. Documentation describing the functional testing process.
Supplemental Material
Draft 1 of PRC‐012‐2
August 2015
The following checklist identifies important RAS information for each existing RAS to be retired that the RAS‐entity shall document and provide to the Reliability Coordinator for review pursuant to Requirement R1.
1. Information necessary to ensure that the Reliability Coordinator is able to understand
the physical and electrical location of the RAS and related facilities.
2. A summary of technical studies, if applicable, upon which the decision to retire the RAS is based.
3. Anticipated date of RAS retirement.
While the documentation necessary to evaluate RAS removals is not as extensive as for
new or functionally modified RAS, it is still vital that, when the RAS is no longer
available, System performance will still meet the appropriate (usually TPL) requirements
for the Contingencies or System conditions that the RAS had been installed to
remediate.
Technical Justification for Attachment 2 Content
Reliability Coordinator RAS Review Checklist
Attachment 2 is a checklist provided to assist the RC in identifying reliability considerations generally relevant to aspects of RAS design and implementation, and also for the purpose of facilitating consistent reviews continent‐wide for each RAS to be installed or functionally modified. Most of the checklist items should be applicable to most RAS. There may be checklist items that are not applicable to a given RAS in which case they may be noted as not applicable and skipped in the RC review. Depending on the specifics of the RAS under review, it is possible that other reliability considerations may be identified during the review. Any other reliability considerations, along with their resolution with respect to the particular RAS under review, should be documented along with the Attachment 2 items that were applicable to the specific RAS under review.
| File Type | application/vnd.openxmlformats-officedocument.wordprocessingml.document |
| Author | Michele Chambers |
| File Modified | 0000-00-00 |
| File Created | 2021-01-22 |