Systems Integration Specialists Company, Inc. The Standards Based Integration Company © Copyright...

Systems Integration Specialists Company, Inc.

The Standards Based Integration Company

© Copyright 2012 SISCO, Inc.

Annual WECC Testing Overview for C-RAS

Version 1.0

© Copyright 2012 SISCO, Inc.2

Outline of Presentation

What has been approved for RAS at SCE

What was presented and “approved” by WECC for the SCE C-RAS

The new proposal

Pastoria Energy Facility (PEF) RAS Auto-Test Feature

WECC RAS Reliability Task Force Presentation

Howard HamApril 29, 2004

Auto-Test Logic Step 1: Push-button initiates test

Required conditions: No line-open conditions exist (LV20 deasserted) No generator trips are present (R1P13 deasserted) Valid data is being received from all stations (LV22 asserted)

Sets latches LT21 (Test Start) and LT22 (Disable Trips)

Resets latches LT23 (Test Fail), LT24 (Test Pass), and LT25 (Test Stop)

Starts 5-second timer (SV1)

Auto-Test Logic Step 2: Latch LT22 does two things

Sends Mirrored Bit 7 to PEF, blocking generator trips Blocks N-2 contingency recognition

Step 3: Confirm PEF trips disabled (LV25 asserts)

Step 4: LV31 asserts, sending Mirrored Bits to all Line Monitor Interface relays to simulate all lines open.

Step 5: Confirm all lines show open (LV21 asserts)

Step 6: Send Mirrored Bits trips to all PEF generators

Step 7: Confirm PEF closed all trip output contacts (LV24 asserts)

Auto-Test Logic Step 8: Test pass or fail

If SV1 has not timed out, latch LT24 (Test Pass) is set. If SV1 times out before reaching step 8, latch LT23 (Test Fail) is set instead.

Step 9: Set latch LT25 (Test Stop) and reset latch LT21 (Test Start)

Step 10: LV31 deasserts, turning off Mirrored Bits to trip PEF generators and to simulate all lines open.

Step 11: When all lines show closed, LV20 deasserts. When all PEF generator trips show open, R1P13 deasserts. LV29 then asserts.

Step 12: Latch LT22 (Disable Trips) resets, which: Stops sending Mirrored Bit 7 to PEF, restoring trip outputs. Unblocks N-2 contingency recognition

Test is now complete.




For C-RAS

Previously presented and concept “approved” by WECC circa 2007

- 8 -

When Analytic is placed into test mode…When Analytic is placed into test mode…

C-RAS Analytic in RASP

(1)

(1) – GOOSE information sent to Analytic’s MPs to go into block mode.

(3) – Analytic begins processing test information once all MPs indicate “blocked”.

(3)

If MPs don’t indicate blocked within a pre-determinedtime, Analytic transitions to a “TEST-FAILURE” status.

C-RAS Analytic in RASP

(1)

(1) – GOOSE information sent to Analytic’s MPs to go into block mode.

(2)

(2) – MP sends status indicating that it is in blocked mode.

(3) – Analytic begins processing test information once all MPs indicate “blocked”.

(3)

If MPs don’t indicate blocked within a pre-determinedtime, Analytic transitions to a “TEST-FAILURE” status.

Previously Presented to WECC

- 9 -

Use cases 1: LM and Analytic 1 placed into Test Mode (simplified)

Use cases 1: LM and Analytic 1 placed into Test Mode (simplified)

LM A1

Substation 1

Substation 2

AN 1

AN 2

AN 3

RASP 1

LM A2

Analytic 1 process test andnon-test data.

Operates MPs that are in“BLOCKED” mode.

Analytic 2 & 3 treat test informationas bad-quality information. Adaptalgorithms based upon MPs in “BLOCKED” mode..

Operates MPs that are not in“BLOCKED” mode.

- 10 -

SCE/WECC Periodic Testing - CurrentSCE/WECC Periodic Testing - Current

Press a button on an LM to instruct a RASP to enter a “special” test mode.

The “special” test mode places the RASP’s MPs into “BLOCKED” mode.

The “special” test mode operates the MPs and “CLOSURE” information is returned to the RASP.

RASP indicates test success to LM where “button” was pressed.




Some new thoughts


What’s changed in thought process:

Verification of Communication Paths

Verification of ability to receive information from Monitoring Relay

Verification of the ability to simulate a line-out from a monitoring relay

Verification of ability to send information to the Mitigation Relay(s)

Verification of ability of the Mitigation Relay to “trip”.

Note: What got tested was “special” test code.


For C-RAS, analysis shows:

Yearly test based upon RAS: Is not efficient.

Decreases overall system availability.

Requires special testing code to be developed per RAS.

Proposed revised testing philosophy, per “IED/Relay” Allows RAS to still operate.

Overlapped relays are tested only once.

Allows individual relays to be tested independently.

Allows test code to be generated once:

One set of code for Monitoring Relays. One set of code for Mitigation Relays.


How it would work (per IED): General Flow

Initialization

Mitigation Relay SequenceMonitoring Relay Sequence

Mitigation Relay Clean-up

Termination

Monitoring Relay Clean-up


Initialization Sequence of testing

Sequence

Place the internal “virtual” IED into year-end test mode.

This causes the associated relay to be commanded to enter “test” mode.

Relay sends back its status that it is in “test” mode.

Resulting states of the initial sequence: Bi-directional communication has been verified with the relay (monitoring or

mitigation).

Relays are in “test” mode.

Analytics understand that a relay is unavailable due to its “test” status being returned.


Mitigation Sequence of testing

Normal Mitigation Testing Sequence

Command LSR to go into safe mode.

This causes the status of the LSR to be returned.

If safe, Command to “close trip contact” is issued.

Status of contacts is returned. Command to “open trip contact” is issued. Status of contacts is returned.

Failure recovery: If can’t enter safe mode, declare failed test.

If can’t “trip”, declare failed test and leave relay in test state.


Mitigation Sequence of testing

Mitigation Clean-up

Command LSR to go back into normal mode.

This causes the status of the LSR to be returned.

Failure recovery: If can’t change LSR, declare failed test and leave relay in test state.


Termination Sequence

Sequence

Remove year-end-test mode from the internal “virtual” IED

This causes the associated relay to be commanded to leave “test” mode.

Relay sends back its status that it is not in “test” mode.

Resulting states of the initial sequence: Bi-directional communication has been verified with the relay (monitoring or

mitigation).

Relays are no longer in test mode.

Analytics understand that a relay is available due to its “test” status being returned.


Monitoring Relay Sequences

Similar to Mitigation Relay sequence.

Tests the ability to simulate line out status.


Testing 2-of-3 Voting in C-RAS

Only applies to Mitigation Relays

Requires coordination of the three UAPs within the system.

Preliminary Relay GOOSE Layout

Test Mode

Auto-Test ModeContact Status*Rxd CMD UAP1Rxd CMD UAP2Rxd CMD UAP3

Status Information

Needs Attention

- Used by Yearly Test

* SCE uses relay latched contacts Instead of LSRs now.


Does the 2-of-3 voting need to be tested?

Know that the message/trip was received and from which UAP.

Know that the contact can operate.

Just don’t know if the 2-of-3 voting logic was changed.

Preliminary Relay GOOSE Layout

Test Mode

Auto-Test ModeContact Status*Rxd CMD UAP1Rxd CMD UAP2Rxd CMD UAP3

Status Information

Needs Attention

- Used by Yearly Test


No change in test coverage

Testing of Item RAS C-RAS Proposed

Comm Path Up Monitoring/Mitigation Monitoring/Mitigation Monitoring/Mitigation

Comm Path Down Mitigation/Mitigation Monitoring/Mitigation Monitoring/Mitigation

Test Code Execution Yes Yes Yes

Attempt to Trip CB Yes Yes Yes

Simulation of Line Out Yes Yes Yes


Benefits

RAS continue to operate (minus one relay). Increases availability

Code is re-usable

Allows for independent testing of individual relays

Overlapping relays only tested once.

Systems Integration Specialists Company, Inc. The Standards Based Integration Company © Copyright...

Documents

Transcript of Systems Integration Specialists Company, Inc. The Standards Based Integration Company © Copyright...