PRC-012-2

Status: Original and derived artifacts are available for this document.

Download: pdf

PRC-012-2 – Remedial Action Schemes
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. Planning Coordinator
4.1.3. RAS-entity – the Transmission Owner, Generator Owner, or Distribution
Provider that owns all or part 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
R1.

Prior to placing a new or functionally modified RAS in service or retiring an existing
RAS, each RAS-entity shall provide the information identified in Attachment 1 for
review to the Reliability Coordinator(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.
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 each 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.
R3.

Prior to placing a new or functionally modified RAS in service or retiring an existing
RAS, each RAS‐entity that receives feedback from the reviewing Reliability
Coordinator(s) identifying reliability issue(s) shall resolve each issue to obtain
approval of the RAS from each reviewing Reliability Coordinator. [Violation Risk
Factor: Medium] [Time Horizon: Operations Planning]
Page 1 of 49

PRC-012-2 – Remedial Action Schemes
M3. Acceptable evidence may include, but is not limited to, dated documentation and
communications with the reviewing Reliability Coordinator that no reliability issues
were identified during the review or that all identified reliability issues were resolved
in accordance with Requirement R3.
R4.

Each Planning Coordinator, at least once every five full calendar years, shall:
[Violation Risk Factor: Medium] [Time Horizon: Long-term Planning]
4.1. Perform an evaluation of each RAS within its planning area to determine
whether:
4.1.1. The RAS mitigates the System condition(s) or Contingency(ies) for which
it was designed.
4.1.2. The RAS avoids adverse interactions with other RAS, and protection and
control systems.
4.1.3. For limited impact 1 RAS, the inadvertent operation of the RAS or the
failure of the RAS to operate does not cause or contribute to BES
Cascading, uncontrolled separation, angular instability, voltage instability,
voltage collapse, or unacceptably damped oscillations.
4.1.4. Except for limited impact RAS, the possible inadvertent operation of the
RAS, resulting from any single RAS component malfunction satisfies all of
the following:
4.1.4.1.

The BES shall remain stable.

4.1.4.2.

Cascading shall not occur.

4.1.4.3.

Applicable Facility Ratings shall not be exceeded.

4.1.4.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.1.4.5.

Transient voltage responses shall be within acceptable limits
as established by the Transmission Planner and the Planning
Coordinator.

4.1.5. Except for limited impact RAS, 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.

1 A RAS designated as limited impact cannot, by inadvertent operation or failure to operate, cause or contribute to BES

Cascading, uncontrolled separation, angular instability, voltage instability, voltage collapse, or unacceptably damped
oscillations.

Page 2 of 49

PRC-012-2 – Remedial Action Schemes
4.2. Provide the results of the RAS evaluation including any identified deficiencies to
each reviewing Reliability Coordinator and RAS-entity, and each impacted
Transmission Planner and Planning Coordinator.
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-entity(ies), Transmission Planner(s), Planning
Coordinator(s), and the reviewing Reliability Coordinator(s) in accordance with
Requirement R4.
R5.

Each RAS-entity, within 120 full calendar days of a RAS operation or a failure of its RAS
to operate when expected, or on a mutually agreed upon schedule with its reviewing
Reliability Coordinator(s), shall: [Violation Risk Factor: Medium] [Time Horizon:
Operations Planning]
5.1. Participate in analyzing the RAS operational performance to determine whether:
5.1.1. The System events and/or conditions appropriately triggered the RAS.
5.1.2. The RAS responded as designed.
5.1.3. The RAS was effective in mitigating BES performance issues it was
designed to address.
5.1.4. The RAS operation resulted in any unintended or adverse BES response.
5.2. Provide the results of RAS operational performance analysis that identified any
deficiencies to its reviewing Reliability Coordinator(s).

M5. Acceptable evidence may include, but is not limited to, dated documentation detailing
the results of the RAS operational performance analysis and dated communications
with participating RAS-entities and the reviewing Reliability Coordinator(s) in
accordance with Requirement R5.
R6.

Each RAS-entity shall participate in developing a Corrective Action Plan (CAP) and
submit the CAP to its reviewing Reliability Coordinator(s) within six full calendar
months of: [Violation Risk Factor: Medium] [Time Horizon: Operations Planning, Longterm Planning]
•

Being notified of a deficiency in its RAS pursuant to Requirement R4, or

•

Notifying the Reliability Coordinator of a deficiency pursuant to Requirement R5,
Part 5.2, or

•

Identifying a deficiency in its RAS pursuant to Requirement R8.

M6. Acceptable evidence may include, but is not limited to, a dated CAP and dated
communications among each reviewing Reliability Coordinator and each RAS-entity in
accordance with Requirement R6.

Page 3 of 49

PRC-012-2 – Remedial Action Schemes
R7.

Each RAS-entity shall, for each of its CAPs developed pursuant to Requirement R6:
[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
and when the CAP is completed.

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 reviewing Reliability
Coordinator(s) that documents the implementation, updating, or completion of a CAP
in accordance with Requirement R7.
R8.

Each RAS-entity shall participate in performing a functional test of each of its 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]
•

At least once every six full calendar years for all RAS not designated as limited
impact, or

•

At least once every twelve full calendar years for all RAS designated as limited
impact

M8. Acceptable evidence may include, but is not limited to, dated documentation detailing
the RAS operational performance analysis for a correct RAS segment or an end-to-end
operation (Measure M5 documentation), or dated documentation demonstrating that
a functional test of each RAS segment or an end-to-end test was performed in
accordance with Requirement R8.
R9.

Each Reliability Coordinator shall update a RAS database containing, at a minimum,
the information in Attachment 3 at least once every twelve full calendar months.
[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 updated 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.

1.2.

Evidence Retention:

Page 4 of 49

PRC-012-2 – Remedial Action Schemes
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 RAS-entity (Transmission Owner, Generator Owner, and Distribution
Provider) shall each keep data or evidence to show compliance with
Requirements R1, R3, R5, R6, R7, and R8, and Measures M1, M3, M5, M6, M7,
and M8 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.
The Reliability Coordinator shall each keep data or evidence to show compliance
with Requirements R2 and R9, and Measures M2 and 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.
The Planning Coordinator shall each keep data or evidence to show compliance
with Requirement R4 and Measure M4 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 RAS-entity (Transmission Owner, Generator Owner or Distribution Provider),
Reliability Coordinator, or Planning Coordinator is found non-compliant, 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.

Page 5 of 49

PRC-012-2 – Remedial Action Schemes
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
provide the information
identified in Attachment 1 to
each Reliability Coordinator
prior to placing a new or
functionally modified RAS in
service or retiring an existing
RAS in accordance with
Requirement R1.

R2.

The reviewing Reliability
Coordinator performed the
review and provided the
written feedback in
accordance with
Requirement R2, but was
late by less than or equal to
30 full 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 full
calendar days but less than
or equal to 60 full 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 full
calendar days but less than
or equal to 90 full 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 full
calendar days.

Page 6 of 49

OR
The reviewing Reliability
Coordinator failed to
perform the review or
provide feedback in
accordance with
Requirement R2.

PRC-012-2 – Remedial Action Schemes
R#

Violation Severity Levels
Lower VSL

Moderate VSL

High VSL

Severe VSL

R3.

N/A

N/A

N/A

The RAS-entity failed to
resolve identified reliability
issue(s) 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 Planning Coordinator
performed the evaluation in
accordance with
Requirement R4, but was
late by less than or equal to
30 full calendar days.

The Planning Coordinator
performed the evaluation in
accordance with
Requirement R4, but was
late by more than 30 full
calendar days but less than
or equal to 60 full calendar
days.

The Planning Coordinator
performed the evaluation in
accordance with
Requirement R4, but was
late by more than 60 full
calendar days but less than
or equal to 90 full calendar
days.

The Planning Coordinator
performed the evaluation in
accordance with
Requirement R4, but was
late by more than 90 full
calendar days.

OR
The Planning Coordinator
performed the evaluation in
accordance with
Requirement R4, but failed
to evaluate one of the Parts
4.1.1 through 4.1.5.

Page 7 of 49

OR
The Planning Coordinator
performed the evaluation in
accordance with
Requirement R4, but failed
to evaluate two or more of
the Parts 4.1.1 through 4.1.5.
OR

PRC-012-2 – Remedial Action Schemes
R#

Violation Severity Levels
Lower VSL

Moderate VSL

High VSL

Severe VSL

The Planning Coordinator
performed the evaluation in
accordance with
Requirement R4, but failed
to provide the results to one
or more of the receiving
entities listed in Part 4.2.
OR
The Planning Coordinator
failed to perform the
evaluation in accordance
with Requirement R4.
R5.

The RAS-entity performed
the analysis in accordance
with Requirement R5, but
was late by less than or
equal to 10 full calendar
days.

The RAS-entity performed
the analysis in accordance
with Requirement R5, but
was late by more than 10 full
calendar days but less than
or equal to 20 full calendar
days.

The RAS-entity performed
the analysis in accordance
with Requirement R5, but
was late by more than 20 full
calendar days but less than
or equal to 30 full calendar
days.
OR
The RAS-entity performed
the analysis in accordance
with Requirement R5, but
failed to address one of the
Parts 5.1.1 through 5.1.4.

Page 8 of 49

The RAS-entity performed
the analysis in accordance
with Requirement R5, but
was late by more than 30 full
calendar days.
OR
The RAS-entity performed
the analysis in accordance
with Requirement R5, but
failed to address two or
more of the Parts 5.1.1
through 5.1.4.

PRC-012-2 – Remedial Action Schemes
R#

Violation Severity Levels
Lower VSL

Moderate VSL

High VSL

Severe VSL

OR
The RAS-entity performed
the analysis in accordance
with Requirement R5, but
failed to provide the results
(Part 5.2) to one or more of
the reviewing Reliability
Coordinator(s).
OR
The RAS-entity failed to
perform the analysis in
accordance with
Requirement R5.
R6.

The RAS-entity 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 full calendar days.

Page 9 of 49

The RAS-entity 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 full
calendar days but less than
or equal to 20 full calendar
days.

The RAS-entity 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 full
calendar days but less than
or equal to 30 full calendar
days.

The RAS-entity 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 full
calendar days.
OR
The RAS-entity developed a
Corrective Action Plan but
failed to submit it to one or

PRC-012-2 – Remedial Action Schemes
R#

Violation Severity Levels
Lower VSL

Moderate VSL

High VSL

Severe VSL

more of its reviewing
Reliability Coordinator(s) in
accordance with
Requirement R6.
OR
The RAS-entity failed to
develop a Corrective Action
Plan in accordance with
Requirement R6.
R7.

The RAS-entity implemented N/A
a CAP in accordance with
Requirement R7, Part 7.1,
but failed to update the CAP
(Part 7.2) if actions or
timetables changed, or failed
to notify (Part 7.3) each of
the reviewing Reliability
Coordinator(s) of the
updated CAP or completion
of the CAP.

N/A

The RAS-entity failed to
implement a CAP in
accordance with
Requirement R7, Part 7.1.

R8.

The RAS-entity performed
the functional test for a RAS
as specified in Requirement
R8, but was late by less than

The RAS-entity performed
the functional test for a RAS
as specified in Requirement
R8, but was late by more
than 60 full calendar days

The RAS-entity performed
the functional test for a RAS
as specified in Requirement
R8, but was late by more
than 90 full calendar days.

Page 10 of 49

The RAS-entity performed
the functional test for a RAS
as specified in Requirement
R8, but was late by more
than 30 full calendar days

PRC-012-2 – Remedial Action Schemes
R#

R9.

Violation Severity Levels
Lower VSL

Moderate VSL

High VSL

Severe VSL

or equal to 30 full calendar
days.

but less than or equal to 60
full calendar days.

but less than or equal to 90
full calendar days.

OR

The Reliability Coordinator
updated the RAS database in
accordance with
Requirement R9, but was
late by less than or equal to
30 full calendar days.

The Reliability Coordinator
updated the RAS database in
accordance with
Requirement R9, but was
late by more than 30 full
calendar days but less than
or equal to 60 full calendar
days.

The Reliability Coordinator
updated the RAS database in
accordance with
Requirement R9, but was
late by more than 60 full
calendar days but less than
or equal to 90 full calendar
days.

Page 11 of 49

The RAS-entity failed to
perform the functional test
for a RAS as specified in
Requirement R8.
The Reliability Coordinator
updated the RAS database in
accordance with
Requirement R9 but was late
by more than 90 full
calendar days.
OR
The Reliability Coordinator
failed to update the RAS
database in accordance with
Requirement R9.

PRC-012-2 – Remedial Action Schemes
D. Regional Variances
None.
E. Associated Documents
Version History
Version

0

Date

Action

February 8, 2005 Adopted by the Board of Trustees
March 16, 2007

Identified by Commission as “fill-in-the-blank” with
no action taken on the standard

1

November 13,
2014

Adopted by the Board of Trustees

1

November 19,
2015

Accepted by Commission for informational
purposes only

2

May 5, 2016

Adopted by Board of Trustees

2

September 20,
2017

FERC Order No. 837 issued approving PRC-012-2

0

Page 12 of 49

Change Tracking

Attachments
Attachment 1
Supporting Documentation for RAS Review

The following checklist identifies important Remedial Action Scheme (RAS) information for
each new or functionally modified 2 RAS that the RAS-entity must document and provide to
the reviewing Reliability Coordinator(s) (RC). If an item on this list does not apply to a
specific RAS, a response of “Not Applicable” for that item is appropriate. When RAS are
submitted for functional modification review and approval, only the proposed modifications
to that RAS require review; however, the RAS-entity must provide a summary of the existing
functionality. The RC may request additional information on any aspect of the RAS as well as
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.
4. Data to populate the RAS database:
a. RAS name.
b. Each 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, 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. Identification of limited impact 3 RAS.
h. Any additional explanation relevant to high-level understanding of the RAS.

2 Functionally modified: Any modification to a RAS consisting of any of the following:

•
Changes to System conditions or contingencies monitored by the RAS
•
Changes to the actions the RAS is designed to initiate
•
Changes to RAS hardware beyond in-kind replacement; i.e., match the original functionality of existing components
•
Changes to RAS logic beyond correcting existing errors
•
Changes to redundancy levels; i.e., addition or removal
3 A RAS designated as limited impact cannot, by inadvertent operation or failure to operate, cause or contribute to BES
Cascading, uncontrolled separation, angular instability, voltage instability, voltage collapse, or unacceptably damped
oscillations.

Page 13 of 49

Attachments
II.

Functional Description and Transmission Planning Information

1. Contingencies and System conditions that the RAS is intended to remedy.
2. The action(s) to be taken by the RAS in response to disturbance conditions.
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.
4. Information regarding any future System plans that will impact the RAS.
5. RAS-entity proposal and justification for limited impact designation, if applicable.
6. Documentation describing the System performance resulting from the possible
inadvertent operation of the RAS, except for limited impact RAS, caused by any single
RAS component malfunction. Single component malfunctions in a RAS not determined
to be limited impact must satisfy 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.
7. An evaluation indicating that the RAS settings and operation avoid adverse interactions
with other RAS, and protection and control systems.
8. Identification of other affected RCs.

Page 14 of 49

Attachments
III. Implementation

1. Documentation describing the applicable equipment used for detection, dc supply,
communications, transfer trip, logic processing, control actions, and monitoring.
2. Information on detection logic and settings/parameters that control the operation of
the RAS.
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.
4. Documentation describing the System performance resulting from a single component
failure in the RAS, except for limited impact RAS, when the RAS is intended to operate. A
single component failure in a RAS not determined to be limited impact must 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.
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.

Page 15 of 49

Attachments
Attachment 2
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 modified 4 Remedial Action Scheme (RAS).
The RC review is not limited to the checklist items and the RC may request additional
information on any aspect of the RAS as well as any reliability issue related to the RAS. If a
checklist item is not relevant to a particular RAS, it should be noted as “Not Applicable.” If
reliability considerations are identified during the review, the considerations and the proposed
resolutions should be documented with the remaining applicable Attachment 2 items.
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 designed timing of RAS operation(s) is appropriate to its BES performance
objectives.
3. The RAS arming conditions, if applicable, are appropriate to its System performance
objectives.
4. The RAS avoids adverse interactions with other RAS, and protection and control
systems.
5. The effects of RAS incorrect operation, including inadvertent operation and failure to
operate, have been identified.
6. Determination whether or not the RAS is limited impact. 5 A RAS designated as limited
impact cannot, by inadvertent operation or failure to operate, cause or contribute to
BES Cascading, uncontrolled separation, angular instability, voltage instability, voltage
collapse, or unacceptably damped oscillations.
7. Except for limited impact RAS as determined by the RC, 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.

4 Functionally modified: Any modification to a RAS consisting of any of the following:

•
Changes to System conditions or contingencies monitored by the RAS
•
Changes to the actions the RAS is designed to initiate
•
Changes to RAS hardware beyond in-kind replacement; i.e., match the original functionality of existing components
•
Changes to RAS logic beyond correcting existing errors
•
Changes to redundancy levels; i.e., addition or removal
5 A RAS designated as limited impact cannot, by inadvertent operation or failure to operate, cause or contribute to BES
Cascading, uncontrolled separation, angular instability, voltage instability, voltage collapse, or unacceptably damped
oscillations.

Page 16 of 49

Attachments
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.
8. 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. Except for limited impact RAS as determined by the RC, 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.
3. The RAS design facilitates periodic testing and maintenance.
4. The mechanism or procedure by which the RAS is armed is clearly described, and is
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.

Page 17 of 49

Attachments
Attachment 3
Database Information

1. RAS name.
2. Each 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. Identification of limited impact 6 RAS.
8. Any additional explanation relevant to high-level understanding of the RAS.

6 A RAS designated as limited impact cannot, by inadvertent operation or failure to operate, cause or contribute to BES

Cascading, uncontrolled separation, angular instability, voltage instability, voltage collapse, or unacceptably damped
oscillations.

Page 18 of 49

Supplemental Material
Technical Justification

4.1.1 Reliability Coordinator
The Reliability Coordinator (RC) is the best-suited functional entity to perform the Remedial
Action Scheme (RAS) review because the RC has the widest area reliability perspective of all
functional entities and an awareness of reliability issues in neighboring RC Areas. The Wide
Area purview better facilitates the evaluation of interactions among separate RAS, as well as
interactions among 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, Transmission Planner, or other
entities involved in the planning or implementation of a RAS. The RC is also less likely to be a
stakeholder in any given RAS and can therefore maintain objective independence.
4.1.2 Planning Coordinator
The Planning Coordinator (PC) is the best-suited functional entity to perform the RAS evaluation
to verify the continued effectiveness and coordination of the RAS, its inadvertent operation
performance, and the performance for a single component failure. The items that must be
addressed in the evaluations include: 1) RAS mitigation of the System condition(s) or event(s)
for which it was designed; 2) RAS avoidance of adverse interactions with other RAS and with
protection and control systems; 3) the impact of inadvertent operation; and 4) the impact of a
single component failure. The evaluation of these items involves modeling and studying the
interconnected transmission system, similar to the planning analyses performed by PCs.
4.1.3 RAS-entity
The RAS-entity is any Transmission Owner, Generator Owner, or Distribution Provider that
owns all or part of a RAS. If all of the RAS (RAS components) have a single owner, then that RASentity has sole responsibility for all the activities assigned within the standard to the RAS-entity.
If the RAS (RAS components) have more than one owner, then each separate RAS component
owner is a RAS-entity and is obligated to participate in various activities identified by the
Requirements.
The standard does not stipulate particular compliance methods. RAS-entities have the option of
collaborating to fulfill their responsibilities for each applicable requirement. Such collaboration
and coordination may promote efficiency in achieving the reliability objectives of the
requirements; however, the individual RAS-entity must be able to demonstrate its participation
for compliance. As an example, the individual RAS-entities could collaborate to produce and
submit a single, coordinated Attachment 1 to the reviewing RC pursuant to Requirement R1 to
initiate the RAS review process.
Limited impact
RAS are unique and customized assemblages of protection and control equipment that vary in
complexity and impact on the reliability of the BES. These differences in RAS design, action, and
risk to the BES are identified and verified within the construct of Requirements R1-R4 of PRC012-2.
The reviewing RC has the authority to designate a RAS as limited impact if the RAS cannot, by
inadvertent operation or failure to operate, cause or contribute to BES Cascading, uncontrolled
Page 19 of 49

Supplemental Material
separation, angular instability, voltage instability, voltage collapse, or unacceptably damped
oscillations. The reviewing RC makes the final determination as to whether a RAS qualifies for
the limited impact designation based upon the studies and other information provided with the
Attachment 1 submittal by the RAS-entity.
The standard recognizes the Local Area Protection Scheme (LAPS) classification in WECC
(Western Electricity Coordinating Council) and the Type III classification in NPCC (Northeast
Power Coordinating Council) as initially appropriate for limited impact designation. The
following information describing the aforementioned WECC and NPCC RAS is excerpted from
the respective regional documentation 7.The drafting team notes that the information below
represents the state of the WECC and NPCC regional processes at the time of this standard
development and is subject to change before the effective date of PRC-012-2.
WECC: Local Area Protection Scheme (LAPS)
A Remedial Action Scheme (RAS) whose failure to operate would NOT result in any of the
following:
•

Violations of TPL-001-WECC-RBP System Performance RBP,

•

Maximum load loss ≥ 300 MW,

•

Maximum generation loss ≥ 1000 MW.

NPCC: Type III
An SPS whose misoperation or failure to operate results in no significant adverse impact
outside the local area.
The following terms are also defined by NPCC to assess the impact of the SPS for
classification:
Significant adverse impact – With due regard for the maximum operating capability of the
affected systems, one or more of the following conditions arising from faults or disturbances,
shall be deemed as having significant adverse impact:
a. system instability;
b. unacceptable system dynamic response or equipment tripping;
c. voltage levels in violation of applicable emergency limits;
d. loadings on transmission facilities in violation of applicable emergency limits;
e. unacceptable loss of load.
Local area – An electrically confined or radial portion of the system. The geographic size and
number of system elements contained will vary based on system characteristics. A local area
may be relatively large geographically with relatively few buses in a sparse system, or be

7 WECC Procedure to Submit a RAS for Assessment Information Required to Assess the Reliability of a RAS Guideline, Revised

10/28/2013 | NPCC Regional Reliability Reference Directory # 7, Special Protection Systems, Version 2, 3/31/2015

Page 20 of 49

Supplemental Material
relatively small geographically with a relatively large number of buses in a densely networked
system.
A RAS implemented prior to the effective date of PRC-012-2 that has been through the regional
review processes of WECC or NPCC and classified as either a Local Area Protection Scheme
(LAPS) in WECC or a Type III in NPCC, is recognized as a limited impact RAS upon the effective
date of PRC-012-2 for the purposes of this standard and is subject to all applicable
requirements.
To propose an existing RAS (a RAS implemented prior to the effective date of PRC-012-2) be
designated as limited impact by the reviewing RC, the RAS-entity must prepare and submit the
appropriate Attachment 1 information that includes the technical justification (evaluations)
documenting that the System can meet the performance requirements (specified in
Requirement R4, Parts 4.1.4 and 4.1.5) resulting from a single RAS component malfunction or
failure, respectively.
There is nothing that precludes a RAS-entity from working with the reviewing RC during the
implementation period of PRC-012-2, in anticipation of the standard becoming enforceable.
However, even if the reviewing RC determines the RAS qualifies as limited impact, the
designation is not relevant until the standard becomes effective. Until then, the existing
regional processes remain in effect as well as the existing RAS classifications or lack thereof.
An example of a scheme that could be recognized as a limited impact RAS is a load shedding or
generation rejection scheme used to mitigate the overload of a BES transmission line. The
inadvertent operation of such a scheme would cause the loss of either a certain amount of
generation or load. The evaluation by the RAS-entity should demonstrate that the loss of this
amount of generation or load, without the associated contingency for RAS operation actually
occurring, is acceptable and not detrimental to the reliability of BES; e.g., in terms of frequency
and voltage stability. The failure of that scheme to operate when intended could potentially
lead to the overloading of a transmission line beyond its acceptable rating. The RAS-entity
would need to demonstrate that this overload, while in excess of the applicable Facility Rating,
is not detrimental to the BES outside the contained area (predetermined by studies) affected by
the contingency.
Other examples of limited impact RAS include:
•

A scheme used to protect BES equipment from damage caused by overvoltage through
generation rejection or equipment tripping.

•

A centrally-controlled undervoltage load shedding scheme used to protect a contained
area (predetermined by studies) of the BES against voltage collapse.

•

A scheme used to trip a generating unit following certain BES Contingencies to prevent
the unit from going out of synch with the System; where, if the RAS fails to operate and
the unit pulls out of synchronism, the resulting apparent impedance swings do not

Page 21 of 49

Supplemental Material
result in the tripping of any Transmission System Elements other than the generating
unit and its directly connected Facilities.
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.
Functional modifications consists of any of the following:
•

Changes to System conditions or Contingencies monitored by the RAS

•

Changes to the actions the RAS is designed to initiate

•

Changes to RAS hardware beyond in-kind replacement; i.e., match the original
functionality of existing components

•

Changes to RAS logic beyond correcting existing errors

•

Changes to redundancy levels; i.e., addition or removal

An example indicating the limits of an in-kind replacement of a RAS component is the
replacement of one relay (or other device) with a relay (or other device) that uses similar
functions. For instance, if a RAS included a CO-11 relay which was replaced by an IAC-53 relay,
that would be an in-kind replacement. If the CO-11 relay were replaced by a microprocessor
SEL-451 relay that used only the same functions as the original CO-11 relay, that would also be
an in-kind replacement; however, if the SEL-451 relay was used to add new logic to what the
CO-11 relay had provided, then the replacement relay would be a functional modification.
Changes to RAS pickup levels that require no other scheme changes are not considered a
functional modification. For example, System conditions require a RAS to be armed when the
combined flow on two lines exceeds 500 MW. If a periodic evaluation pursuant to Requirement
R4, or other assessment, indicates that the arming level should be reduced to 450 MW without
requiring any other RAS changes that would not be a functional modification. Similarly, if a RAS
is designed to shed load to reduce loading on a particular line below 1000 amps, then a change
in the load shedding trigger from 1000 amps to 1100 amps would not be a functional
modification.
Another example illustrates a case where a System change may result in a RAS functional
change. Assume that a generation center is connected to a load center through two
transmission lines. The lines are not rated to accommodate full plant output if one line is out of
service, so a RAS monitors the status of both lines and trips or ramps down the generation to a
safe level following loss of either line. Later, one of the lines is tapped to serve additional load.
The System that the RAS impacts now includes three lines, loss of any of which is likely to still
require generation reduction. The modified RAS will need to monitor all three lines (add two
line terminal status inputs to the RAS) and the logic to recognize the specific line outages would
Page 22 of 49

Supplemental Material
change, while the generation reduction (RAS output) requirement may or may not change,
depending on which line is out of service. These required RAS changes would be a functional
modification.
Any functional modification to a RAS will need to be reviewed and approved through the
process described in Requirements R1, R2, and R3. The need for such functional modifications
may be identified in several ways including but not limited to the Planning evaluations pursuant
to R4, incorrect operations pursuant to R5, a test failure pursuant to R8, or Planning
assessments related to future additions or modifications of other facilities.
See Item 4a in the Implementation Section of Attachment 1 in the Supplemental Material
section for typical RAS components for which a failure may be considered. The RC has the
discretion to make the final determination regarding which components should be regarded as
RAS components during its review.
To facilitate a review that promotes reliability, the RAS-entity(ies) 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(ies) 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(ies)
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 reliability issues that might be identified, in order to obtain approval
of the reviewing RC. Expeditious submittal of this information is in the interest of each RASentity 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-entity(ies). An independent review by a multi-disciplinary panel of subject matter experts
with planning, operations, protection, telecommunications, 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
Page 23 of 49

Supplemental Material
neighboring RC Areas. This Wide Area purview 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. It is recognized that the RC does not
possesses more information or ability than anticipated by their functional registration as
designated by NERC. The NERC Functional Model is a guideline for the development of
standards and their applicability and does not contain compliance requirements. If Reliability
Standards address functions that are not described in the model, the Reliability Standard
requirements take precedence over the Functional Model. For further reference, please see the
Introduction section of NERC’s Reliability Functional Model, Version 5, November 2009.
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 RAS submitted
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.
Requirement R3

Requirement R3 mandates that each RAS-entity resolve all reliability issues (pertaining to its
RAS) identified during the RAS review by the reviewing Reliability Coordinators. Examples of
reliability issues include a lack of dependability, security, or coordination. RC approval of a RAS
is considered to be obtained when the reviewing RC’s feedback to each RAS-entity indicates
that either no reliability issues were identified during the review or all identified reliability
issues were resolved to the RC’s satisfaction.
Dependability is a component of reliability that 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 that 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
Page 24 of 49

Supplemental Material
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 PRC012-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 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-entity to effect a timely
implementation.
A specific time period for the RC to respond to the RAS-entity following the RAS review is also
not necessary because the RC will be aware of (1) any reliability issues associated with the RAS
not being in service and (2) the RAS-entity’s schedule to implement the RAS to address those
reliability issues. Since the RC is the ultimate arbiter of BES operating reliability, resolving
reliability issues is a priority for the RC and serves as an incentive to expeditiously respond to
the RAS-entity.
Requirement R4

Requirement R4 mandates that an evaluation of each RAS be performed at least once every five
full calendar years. 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 may change the effectiveness of a RAS or the way it interacts with and impacts the
BES.
A RAS designated as limited impact cannot, by inadvertent operation or failure to operate,
cause or contribute to BES Cascading, uncontrolled separation, angular instability, voltage
instability, voltage collapse, or unacceptably damped oscillations. Limited impact RAS are not
subject to the RAS single component malfunction and failure tests of Parts 4.1.4 and 4.1.5,
respectively. Requiring a limited impact RAS to meet these tests would add complexity to the
design with minimal benefit to BES reliability.
A RAS implemented after the effective date of this standard can only be designated as limited
impact by the reviewing RC(s). A RAS implemented prior to the effective date of PRC-012-2 that
has been through the regional review processes of WECC or NPCC and is classified as either a
Local Area Protection Scheme (LAPS) in WECC or a Type III in NPCC is recognized as a limited
impact RAS upon the effective date of PRC-012-2 for the purposes of this standard and is
subject to all applicable requirements.
Page 25 of 49

Supplemental Material
Requirement R4 also clarifies that the RAS single component failure and inadvertent operation
tests do not apply to RAS which are determined to be limited impact. Requiring a limited impact
RAS to meet the single component failure and inadvertent operation tests would just add
complexity to the design with little or no improvement in the reliability of the BES.
For existing RAS, the initial performance of Requirement R4 must be completed within five full
calendar years of the effective date of PRC‐012‐2. For new or functionally modified RAS, the
initial performance of the requirement must be completed within five full calendar years of the
RAS approval date by the reviewing RC(s). Five full calendar years 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 could potentially impact the effectiveness or coordination of the RAS. System
changes also have the potential to alter the reliability impact of limited impact RAS on the BES.
Requirement 4, Part 4.1.3 explicitly requires the periodic evaluation of limited impact RAS to
verify the limited impact designation remains applicable. 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 evaluations (Requirement R4, Parts 4.1.1 through
4.1.5) are planning analyses that may involve modeling of the interconnected transmission
system to assess BES performance. The PC is the functional entity best suited to perform the
analyses because they have a wide-area planning perspective. To promote reliability, the PC is
required to provide the results of the evaluation to each impacted Transmission Planner and
Planning Coordinator, in addition to each reviewing RC and RAS-entity. In cases where a RAS
crosses PC boundaries, each affected PC is responsible for conducting either individual
evaluations or participating in a coordinated evaluation.
The intent of Requirement R4, Part 4.1.4 is to verify that the possible inadvertent operation of
the RAS (other than limited impact 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; otherwise, the RAS inadvertent operation must satisfy Requirement R4, Part 4.1.4.
The intent of Requirement R4, Part 4.1.4 is also to verify that the possible inadvertent operation
of the RAS (other than limited impact 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
Page 26 of 49

Supplemental Material
standard, the requirement lists the System performance requirements that a potential
inadvertent operation must satisfy. The performance requirements listed (Requirement R4,
Parts 4.1.4.1 – 4.1.4.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.1.4, note that the only differences in performance
requirements among the TPL (P0-P7) events (not common to all of them) concern NonConsequential Load Loss and interruption of Firm Transmission Service. It is not necessary for
Requirement R4, Part 4.1.4 to specify performance requirements related to these areas
because a RAS is only allowed to drop non-consequential load or interrupt Firm Transmission
Service 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.
The intent of Requirement R4, Part 4.1.5 is to verify that a single component failure in a RAS,
other than limited impact 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.
The following is an example of a single component failure causing the System to fail to meet the
performance requirements for the P1 event for which the RAS was installed. Consider the
instance where a three-phase Fault (P1 event) results in a generating plant becoming unstable
(a violation of the System performance requirements of TPL-001-4). To resolve this, a RAS is
installed to trip a single generating unit which allows the remaining units at the plant to remain
stable. If failure of a single component (e.g., relay) in the RAS results in the RAS failing to
operate for the P1 event, the generating plant would become unstable (failing to meet the
System performance requirements of TPL-001-4 for a P1 event).
Requirement R4, Part 4.1.5 does not mandate that all RAS have redundant components. For
example:
•

Consider the instance where a RAS is installed to mitigate an extreme event in TPL-0014. There are no System performance requirements for extreme events; therefore, the
RAS does not need redundancy to meet the same performance requirements as those
required for the events and conditions for which the RAS was designed.

•

Consider a RAS that arms more load or generation than necessary such that failure of
the RAS to drop a portion of load or generation due to that single component failure will
still result in satisfactory System performance, as long as tripping the total armed
amount of load or generation does not cause other adverse impacts to reliability.

Page 27 of 49

Supplemental Material
The scope of the periodic evaluation does not include a new review of the physical
implementation of the RAS, as this was confirmed by the RC during the initial review and
verified by subsequent functional testing. However, it is possible that a RAS design which
previously satisfied requirements for inadvertent RAS operation and single component failure
by means other than component redundancy may fail to satisfy these requirements at a later
time, and must be evaluated with respect to the current System. For example, if the actions of a
particular RAS include tripping load, load growth could occur over time that impacts the
amount of load to be tripped. These changes could result in tripping too much load upon
inadvertent operation and result in violations of Facility Ratings. Alternatively, the RAS might be
designed to trip more 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 and
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 deficiencies that manifested in the
incorrect RAS operation or failure of RAS to operate when expected.
The 120 full 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; however, flexibility is provided by
allowing the parties to negotiate a different schedule for the analysis. To promote reliability,
the RAS-entity(s) is required to provide the results of RAS operational performance analyses to
its reviewing RC(s) if the analyses revealed a deficiency.
The RAS-entity(ies) may need to collaborate with its associated Transmission Planner to
comprehensively analyze RAS operational performance. This is because a RAS operational
performance analysis involves verifying that the RAS operation was triggered correctly (Part
5.1.1), responded as designed (Part 5.1.2), and that the resulting BES response (Parts 5.1.3 and
5.1.4) was consistent with the intended functionality and design of the RAS. Ideally, when there
is more than one RAS-entity for a RAS, the RAS-entities would collaborate to conduct and
submit a single, coordinated operational performance analysis.
Requirement R6

RAS deficiencies potentially pose a reliability risk to the BES. RAS deficiencies may be identified
in the periodic RAS evaluation conducted by the PC in Requirement R4, in the operational
analysis conducted by the RAS-entity in Requirement R5, or in the functional test performed by
the RAS-entity(ies) in Requirement R8. To mitigate potential reliability risks, Requirement R6
Page 28 of 49

Supplemental Material
mandates that each RAS-entity participate in developing a CAP that establishes the mitigation
actions and timetable necessary to address the deficiency.
The RAS-entity(ies) that owns the RAS components, is responsible for the RAS equipment, and
is in the best position to develop the timelines and perform the necessary work to correct RAS
deficiencies. If necessary, the RAS-entity(ies) may request assistance with development of the
CAP from other parties such as its Transmission Planner or Planning Coordinator; however, the
RAS-entity has the responsibility for compliance with this requirement.
A CAP may require functional changes be made to a RAS. In this case, Attachment 1 information
must be submitted to the reviewing RC(s), an RC review must be performed to obtain RC
approval before the RAS-entity can place RAS modifications in service, per Requirements R1,
R2, and R3.
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-entity collaboration on the CAP development, while ensuring that
deficiencies are addressed in a reasonable time. Ideally, when there is more than one RASentity for a RAS, the RAS-entities would collaborate to develop and submit a single, coordinated
CAP. 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. The
possibility of such operating restrictions will incent the RAS-entity to resolve the issue as quickly
as possible.
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 or did not operate as designed.

•

Periodic planning assessment reveals RAS changes are necessary to correct performance or
coordination issues.

•

Equipment failures.

•

Functional testing identifies that a RAS is not operating as designed.

Requirement R7

Requirement R7 mandates that each RAS-entity implement its CAP developed in Requirement
R6 which mitigates the deficiencies identified in Requirements R4, R5, or R8. By definition, a
CAP is: “A list of actions and an associated timetable for implementation to remedy a specific
problem.”
A CAP can be modified if necessary to account for adjustments to the actions or scheduled
timetable of activities. If the CAP is changed, the RAS-entity must notify the reviewing Reliability

Page 29 of 49

Supplemental Material
Coordinator(s). The RAS-entity must also notify the Reliability Coordinator(s) when the CAP has
been completed.
The implementation of a properly developed CAP ensures that RAS deficiencies are mitigated in
a timely manner. 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 CAP is completed.
The possibility of such operating restrictions will incent the RAS-entity to complete the CAP as
quickly as possible.
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 occur 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 with minimum impact to the
BES and should align with expected results. The RAS-entity 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-entity assurance that latent
failures may be identified and also promotes identification of changes in the System that may
have introduced latent failures.
The six and twelve full calendar year functional testing intervals are greater than the annual or
bi-annual periodic testing performed in some NERC Regions. However, these intervals are 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. Longer test intervals for limited impact RAS are acceptable because
incorrect operations or failures to operate present a low reliability risk to the Bulk Power
System.
Functional testing is not synonymous with end-to-end testing. End-to-end testing is an
acceptable method but may not be feasible for many RAS. When end-to-end testing is not
possible, a RAS-entity 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
scheme test, then 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, by default operates the processing logic and
infrastructure of a RAS, but focuses on the RAS inputs as well as the actions initiated by RAS
Page 30 of 49

Supplemental Material
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 the applicable
maximum test interval to demonstrate compliance with the Requirement.
As an example of segment testing, consider a RAS controller implemented using a PLC that
receives System data, such as loading or line status, from distributed devices. These distributed
devices could include meters, protective relays, or other PLCs. In this example RAS, a line
protective relay is used to provide an analog metering quantity to the RAS control PLC. A
functional test would verify that the System data is received from the protective relay by the
PLC, processed by the PLC, and that PLC outputs are appropriate. There is no need to verify the
protective relay’s ability to measure the power system quantities, as this is a requirement for
Protection Systems used as RAS in PRC-005, Table 1-1, Component Type – Protective Relay.
Rather the functional test is focused on the use of the protective relay data at the PLC, including
the communications data path from relay to PLC if this data is essential for proper RAS
operation. Additionally, if the control signal back to the protective relay is also critical to the
proper functioning of this example RAS, then that path is also verified up to the protective
relay. This example describes a test for one segment of a RAS which verifies RAS action, verifies
PLC control logic, and verifies RAS communications.
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-3,
Requirement R8. See Phase 2 of Project 2007-06 for the mapping document from PRC-001 to
other standards regarding notification of RC by TOP if a deficiency is found during testing.
Consequently, it is not necessary to include a similar requirement in this standard.
The initial test interval begins on the effective date of the standard pursuant to the
implementation plan. Subsequently, the maximum allowable interval between functional tests

Page 31 of 49

Supplemental Material
is six full calendar years for RAS that are not designated as limited impact RAS and twelve full
calendar years for RAS that are designated as limited impact RAS. The interval between tests
begins on the date of the most recent successful test for each individual segment or end-to-end
test. A successful test of one segment only resets the test interval clock for that segment. A
RAS-entity may choose to count a correct RAS operation as a qualifying functional test for those
RAS segments which operate. If a System event causes a correct, but partial RAS operation,
separate functional tests of the segments that did not operate are still required within the
maximum test interval that started on the date of the previous successful test of those (nonoperating) segments in order to be compliant with Requirement R8.
Requirement R9

The RAS database required to be maintained by the RC in Requirement R9 ensures information
regarding existing RAS is available. 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 database enables the RC to provide other entities high-level information on existing RAS
that could potentially impact the operational and/or planning activities of that entity. 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
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.

Page 32 of 49

Supplemental Material
Process Flow Diagram

The diagram below depicts the process flow of the PRC-012-2 requirements.

New RAS proposed
or RAS modified/
retired

Attachment 1

Attachment 2

R1
RAS-entity submits
RAS to RC for review

R2
RC Review Process
For new, modified,
or removal of RAS

RC Approves RAS as is

R9
RC updates RAS
database

R3
RAS-entity accepts
approval
Modify RAS per RC
direction

RC identified issues
With RAS

R3
RAS-entity
addresses issues

RAS
Database
Proposed alternative
to RC direction

Dated Report /
Analysis

Dated
communications
with RAS-entity(ies)
& RC

Yes
reset 5-year clock

Does CAP identify
RAS modification?

No

RAS 5-year review

R4
PC – 5-year review
of RAS in the
planning area

RAS operation or
non operation as
intended

Any deficiencies
identified?

R5
RAS entity determines if RAS
operated as intended (120 days
or an accepted alternative
schedule)

R6
RAS-entity proposes
Corrective Action
Plan within 6
months

Yes

No

R7
RAS-entity
implement the CAP
and update the CAP
until complete

Dated
documentation of
non operation or
operation not as
intended to RC

No
Work Management
documents

Maintenance
Records

Yes
Dated
documentation to
state correct
operation

Yes
At least once every 6
years (12 years –
limited impact)

R8
Perform functional
test of RAS

Any deficiencies
identified?
No
Dated
documentation of
functional testing

Page 33 of 49

Supplemental Material
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-entity(ies) to provide a detailed list of information
describing the RAS to the reviewing RC. If there are multiple RAS-entities for a single RAS,
information will be needed from all RAS-entities. Ideally, in such cases, a single RAS-entity will
take the lead to compile all the data identified into a single Attachment 1.
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
modified 8 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 existing 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
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.

8 Functionally modified: Any modification to a RAS consisting of any of the following:

•
•
•
•
•

Changes to System conditions or contingencies monitored by the RAS
Changes to the actions the RAS is designed to initiate
Changes to RAS hardware beyond in-kind replacement; i.e., match the original functionality of existing components
Changes to RAS logic beyond correcting existing errors
Changes to redundancy levels; i.e., addition or removal

Page 34 of 49

Supplemental Material
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, the analysis of an actual RAS operation
pursuant to Requirement R5, or functional test failure pursuant to Requirement R8. 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. Each RAS-entity and contact information.
c. Expected or actual in-service date; most recent (Requirement R3) RC-approval date;
most recent five full calendar year (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. Identification of limited impact 9 RAS.
h. 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
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.

9 A RAS designated as limited impact cannot, by inadvertent operation or failure to operate, cause or contribute to BES

Cascading, uncontrolled separation, angular instability, voltage instability, voltage collapse, or unacceptably damped
oscillations.

Page 35 of 49

Supplemental Material
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 the date 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. RAS-entity proposal and justification for limited impact designation, if applicable.
A RAS designated as limited impact cannot, by inadvertent operation or failure to
operate, cause or contribute to BES Cascading, uncontrolled separation, angular
instability, voltage instability, voltage collapse, or unacceptably damped oscillations. A
RAS implemented prior to the effective date of PRC-012-2 that has been through the
regional review processes of WECC or NPCC and is classified as either a Local Area
Protection Scheme (LAPS) in WECC or a Type 3 in NPCC is recognized as a limited impact
RAS upon the effective date of PRC-012-2 for the purposes of this standard and is
subject to all applicable requirements.
6. Documentation describing the System performance resulting from the possible
inadvertent operation of the RAS, except for limited impact RAS, caused by any single
RAS component malfunction. Single component malfunctions in a RAS not determined
to be limited impact must satisfy all of the following:
[Reference NERC Reliability Standard PRC-012, R1.4]

Page 36 of 49

Supplemental Material
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.
7. 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.
8. 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, dc supply,
communications, transfer trip, logic processing, control actions, 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).

DC Supply

Batteries and charges, or other forms of dc supply for RAS, are commonly also used for
Protection Systems. This is acceptable, and maintenance of such supplies is covered by
PRC-005. However, redundant RAS, when used, should be supplied from separately
protected (fused or breakered) circuits.

Page 37 of 49

Supplemental Material
Communications: Telecommunications Channels

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-entity, or
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

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.
Control Actions

RAS action devices may include a variety of equipment such as transfer trip, protective
relays, and other control devices. These devices receive commands from the logic
processing function (perhaps through telecommunication facilities) and initiate RAS
actions at the sites where action is required.
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.

Page 38 of 49

Supplemental Material


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; e.g.,
redundancy, the minimal status indications should be provided separately for each
RAS.


The minimum status is generally sufficient for operational purposes; however,
where possible it is often useful to provide additional information regarding
partial failures or the status of critical components to allow the RAS-entity 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 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 the
aforementioned, out of step, etc. are dependent on specific scheme requirements,
but some forms may substitute for or enhance other monitoring described in items
‘a’, ‘b’, and ‘c’ above.
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.

Page 39 of 49

Supplemental Material
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.
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 describing the System performance resulting from a single component
failure in the RAS, except for limited impact RAS, when the RAS is intended to operate. A
single component failure in a RAS not determined to be limited impact must 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]
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, but are not limited to the
following:
a. Providing redundancy of RAS components. Typical examples are listed below:
i.

Protective or auxiliary relays used by the RAS.

Page 40 of 49

Supplemental Material
ii.

Communications systems necessary for correct operation of the RAS.

iii.

Sensing devices used to measure electrical or other 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.

Logic processing devices that accept System inputs from RAS components or
other sources, make decisions based on those inputs, or initiate output signals
to take remedial actions.

b. Arming more load or generation than necessary such that failure of the RAS to drop
a portion of load or generation due to that single component failure will still result in
satisfactory System performance, as long as 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.
IV.

RAS Retirement

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 and technical justifications, 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.

Page 41 of 49

Supplemental Material
Technical Justification for Attachment 2 Content
Reliability Coordinator RAS Review Checklist

Attachment 2 is a checklist provided to facilitate consistent reviews continent-wide for new or
functionally modified RAS prior to the RAS installation. The checklist is meant to assist the RC in
identifying reliability-related considerations relevant to various aspects of RAS design and
implementation.
Technical Justifications for Attachment 3 Content
Database Information

Attachment 3 contains the minimum information that the RC must consolidate into its database
for each RAS in its area.
1. RAS name.
•

The name used to identify the RAS.

2. Each RAS-entity and contact information.
•

A reliable phone number or email address should be included to contact each RAS-entity
if more information is needed.

3. Expected or actual in-service date; most recent (Requirement R3) RC-approval date; most
recent five full calendar year (Requirement R4) evaluation date; and, date of retirement, if
applicable.
•

Specify each applicable date.

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

A short description of the reason for installing the RAS is sufficient, as long as the main
System issues addressed by the RAS can be identified by someone with a reliability
need.

5. Description of the Contingencies or System conditions for which the RAS was designed
(initiating conditions).
•

A high level summary of the conditions/Contingencies is expected. Not all combinations
of conditions are required to be listed.

6. Corrective action taken by the RAS.
•

A short description of the actions should be given. For schemes shedding load or
generation, the maximum amount of megawatts should be included.

Page 42 of 49

Supplemental Material
7. Identification of limited impact 10 RAS.
•

Specify whether or not the RAS is designated as limited impact.

8. Any additional explanation relevant to high-level understanding of the RAS.
•

If deemed necessary, any additional information can be included in this section, but is
not mandatory.

10 A RAS designated as limited impact cannot, by inadvertent operation or failure to operate, cause or contribute to BES
Cascading, uncontrolled separation, angular instability, voltage instability, voltage collapse, or unacceptably damped
oscillations.

Page 43 of 49

Supplemental Material
Rationale

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; i.e., removal from service must be completed prior to
implementation or retirement.
Functional modifications consist of any of the following:
•

Changes to System conditions or Contingencies monitored by the RAS

•

Changes to the actions the RAS is designed to initiate

•

Changes to RAS hardware beyond in-kind replacement; i.e., match the original
functionality of existing components

•

Changes to RAS logic beyond correcting existing errors

•

Changes to redundancy levels; i.e., addition or removal

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.
Ideally, when there is more than one RAS-entity for a RAS, the RAS-entities would collaborate
and submit a single, coordinated Attachment 1 to the reviewing RC. In cases where a RAS
crosses RC Area boundaries, each affected RC is responsible for conducting either individual
reviews or participating in a coordinated review.
Rationale for Requirement R2: The RC is the functional entity best suited to perform the RAS
review because it has the widest area operational and reliability perspective of all functional
entities and an awareness of reliability issues in any neighboring RC Area. This Wide Area
purview facilitates the evaluation of interactions among separate RAS as well as interactions
among RAS and other protection and control systems. Review by 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 is not expected to
possess more information or ability than anticipated by their functional registration as
designated by NERC. The RC may request assistance to perform 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 submitted RAS. The
time frame of four full calendar months is consistent with current utility and regional practice;
Page 44 of 49

Supplemental Material
however, flexibility is provided by allowing the RC(s) and RAS-entity(ies) 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.
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 reviewing RC following identification
of any reliability issue(s) is not necessary because the RAS-entity wants to expedite the timely
approval and subsequent implementation of the RAS.
A specific time period for the RC to respond to the RAS-entity following the RAS review is also
not necessary because the RC will be aware of (1) any reliability issues associated with the RAS
not being in service and (2) the RAS-entity’s schedule to implement the RAS to address those
reliability issues. Since the RC is the ultimate arbiter of BES operating reliability, resolving
reliability issues is a priority for the RC and serves as an incentive to expeditiously respond to
the RAS-entity.
Rationale for Requirement R4: Requirement R4 mandates that an evaluation of each RAS be
performed at least once every five full calendar years. The purpose of the periodic RAS
evaluation is to verify the continued effectiveness and coordination of the RAS, as well as to
verify that, if a RAS single component malfunction or single component failure were to occur,
the requirements for BES performance would continue to be satisfied. A periodic evaluation is
required because changes in System topology or operating conditions may change the
effectiveness of a RAS or the way it impacts the BES.
RAS are unique and customized assemblages of protection and control equipment that vary in
complexity and impact on the reliability of the BES. In recognition of these differences, RAS can
be designated by the reviewing RC(s) as limited impact. A limited impact RAS cannot, by
inadvertent operation or failure to operate, cause or contribute to BES Cascading, uncontrolled
separation, angular instability, voltage instability, voltage collapse, or unacceptably damped
oscillations. The “BES” qualifier in the preceding statement modifies all of the conditions that
follow it. Limited impact RAS are not subject to the RAS single component malfunction and
failure tests of Parts 4.1.4 and 4.1.5, respectively. Requiring a limited impact RAS to meet these
tests would add complexity to the design with minimal benefit to BES reliability. See the
Supplemental Material for more on the limited impact designation.
The standard recognizes the Local Area Protection Scheme (LAPS) classification in WECC
(Western Electricity Coordinating Council) and the Type III classification in NPCC (Northeast
Power Coordinating Council) as initially appropriate for limited impact designation. A RAS
implemented prior to the effective date of PRC-012-2 that has been through the regional
Page 45 of 49

Supplemental Material
review processes of WECC or NPCC and is classified as either a Local Area Protection Scheme
(LAPS) in WECC or a Type III in NPCC is recognized as a limited impact RAS upon the effective
date of PRC-012-2 for the purposes of this standard and is subject to all applicable
requirements.
For existing RAS, the initial performance of Requirement R4 must be completed within five full
calendar years of the effective date of PRC‐012‐2. For new or functionally modified RAS, the
initial performance of the requirement must be completed within five full calendar years of the
RAS approval date by the reviewing RC(s). Five full calendar years 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 could potentially impact the effectiveness or coordination of the RAS. System
changes also have the potential to alter the reliability impact of limited impact RAS on the BES.
Requirement 4, Part 4.1.3 explicitly requires the periodic evaluation of limited impact RAS to
verify the limited impact designation remains applicable; the PC can use its discretion as to how
this evaluation is performed. 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 evaluations (Requirement R4, Parts 4.1.1 through
4.1.5) are planning analyses that may involve modeling of the interconnected transmission
system to assess BES performance. The Planning Coordinator (PC) is the functional entity best
suited to perform this evaluation because they have a wide area planning perspective. To
promote reliability, the PC is required to provide the results of the evaluation to each impacted
Transmission Planner and Planning Coordinator, in addition to each reviewing RC and RASentity. In cases where a RAS crosses PC boundaries, each affected PC is responsible for
conducting either individual evaluations or participating in a coordinated evaluation.
The previous version of this standard (PRC-012-1 Requirement 1, R1.4) states “… the
inadvertent operation of a RAS shall meet the same performance requirement (TPL-001-0, TPL002-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, consistent with PRC-012-1 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
Page 46 of 49

Supplemental Material
requirements that the inadvertent operation must satisfy. The performance requirements listed
(Parts 4.1.4.1 – 4.1.4.5) are the ones that are common to all planning events P0-P7 listed in TPL001-4.
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 was 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 full 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-entity is
required to provide the results of RAS operational performance analyses that identified any
deficiencies to its reviewing RC(s).
RAS-entities may need to collaborate with their associated Transmission Planner to
comprehensively analyze RAS operational performance. This is because a RAS operational
performance analysis involves verifying that the RAS operation was triggered correctly (Part
5.1.1), responded as designed (Part 5.1.2), and that the resulting BES response (Parts 5.1.3 and
5.1.4) was consistent with the intended functionality and design of the RAS. Ideally, when there
is more than one RAS-entity for a RAS, the RAS-entities would collaborate to conduct and
submit a single, coordinated operational performance analysis.
Rationale for Requirement R6: Deficiencies identified in the periodic RAS evaluation conducted
by the PC pursuant to Requirement R4, in the operational performance analysis conducted by
the RAS-entity pursuant to Requirement R5, or in the functional test performed by the RASentity pursuant to Requirement R8, potentially pose a reliability risk to the BES. To mitigate
these potential reliability risks, Requirement R6 mandates that each RAS-entity develop a
Corrective Action Plan (CAP) to address the identified deficiency. The CAP contains the
mitigation actions and associated timetable necessary to remedy the specific deficiency. The
RAS-entity may request assistance with CAP development from other parties such as its
Transmission Planner or Planning Coordinator; however, the RAS-entity has the responsibility
for compliance with this requirement.
If the CAP requires that a functional change be made to a RAS, the RAS-entity will need to
submit information identified in Attachment 1 to the reviewing RC(s) prior to placing RAS
modifications in service per Requirement R1.

Page 47 of 49

Supplemental Material
Depending on the complexity of the identified deficiency(ies), development of a CAP may
require studies, and other engineering or consulting work. A maximum time frame of six full
calendar months is specified for RAS-entity collaboration on the CAP development. Ideally,
when there is more than one RAS-entity for a RAS, the RAS-entities would collaborate to
develop and submit a single, coordinated CAP.
Rationale for Requirement R7: Requirement R7 mandates each RAS-entity implement a CAP
(developed in Requirement R6) that mitigates the deficiencies identified in Requirements R4,
R5, or R8. 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, and when the CAP is
completed.
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 six or twelve full calendar year test interval, which begins on the effective date of the
standard pursuant to the PRC-012-2 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 an undiscovered latent failure
that could cause an incorrect operation or failure of the RAS. The RAS-entity 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-toend testing or a segmented approach. For segmented testing, each segment of a RAS must be
tested. Overlapping segments can be tested individually negating the need for complex
maintenance schedules and outages.
The maximum allowable interval between functional tests is six full calendar years for RAS that
are not designated as limited impact RAS and twelve full calendar years for RAS that are
designated as limited impact RAS. The interval between tests begins on the date of the most
recent successful test for each individual segment or end-to-end test. A successful test of one
segment only resets the test interval clock for that segment. A correct operation of a RAS
qualifies as a functional test for those RAS segments which operate (documentation for
compliance with Requirement R5 Part 5.1). If an event causes a partial operation of a RAS, the
segments without an operation will require a separate functional test within the maximum
interval with the starting date determined by the previous successful test of the segments that
did not operate.

Page 48 of 49

Supplemental Material
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 highlevel information on existing RAS that could potentially impact the operational and/or planning
activities of that entity. 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-entities 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. The twelve full calendar month time frame is aligned with industry practice and allows
sufficient time for the RC to collect the appropriate information from RAS-entities and update
the RAS database.

Page 49 of 49