Date post: | 11-Jan-2016 |
Category: |
Documents |
Upload: | myron-bruce |
View: | 214 times |
Download: | 0 times |
Distributed Control of FACTS Devices Using a TransportationModel
Bruce McMillinComputer Science
Mariesa CrowElectrical and Computer Engineering
University of Missouri-RollaRolla, MO 65409-0040
Outline
• FACTS Devices
• Max Flow
• Suitability of Max Flow to Power System
• Distributed Max Flow
• Fault Tolerance of Distributed Max Flow
Project Motivation
• Due to large unidirectional power flows, transmission grids are becoming increasingly susceptible to cascading failures
• Decentralized network control is necessary to rebalance power flow and contain the extent of the cascade
FACTS devices offer a decentralized network-embedded control mechanism
Project Objective
• Develop an effective distributed FACTS control algorithm to mitigate cascading grid failures, either intentional or unintentional
• Make the developed algorithms fault-tolerant using formal methods based on power system specifications
Approach
The embedded controllers will execute graph-theory-based max flow distributed algorithms to identify critical transmission corridors and adjust power flow accordingly to avoid cascading failures
Outline
• FACTS Devices
• Max Flow
• Suitability of Max Flow to Power System
• Distributed Max Flow
• Fault Tolerance of Distributed Max Flow
Example
Max-Flow
• Assign an initial flow to all arcs
• Mark the source and sink
• Search for a node that can be labeled. If none is found, flow is maximum, stop.
• Backtrack the path computing the minimum ij used. Go to previous step.
s a t100 40
=40
60
0
17
28
50
50
22
815
10
30
320
s
a
e
d
c
b
t
100
40
17
28
50
50
22
815
10
30
320
s
a
e
d
c
b
t
100
40
17
28
50
50
22
815
10
30
320
s
a
e
d
c
b
t
s
45
17
28
50
50
22
80
10
30
35
a
e
d
c
b
t
60
17
28
50
50
22
815
10
30
320
a
e
d
c
b
t
s
60
17
28
50
50
22
815
10
30
320
a
e
d
c
b
t
s
28
28
50
50
22
8
10
13
35
a
e
d
c
b
t
s
45
17
28
50
50
22
8
10
30
35
a
e
d
c
b
t
s
45
17
28
50
50
22
8
10
30
35
a
e
d
c
b
t
s
28
0
28
50
50
22
8
10
13
35
a
e
d
c
b
t
s
28
28
50
50
22
8
10
13
35
a
e
d
c
b
t
s
0
0
22
50
22
8
10
13
35
a
e
d
c
b
t
s
22
50
22
8
10
13
35
e
d
c
b
t
s
22
50
22
8
10
13
35
e
d
c
b
s
0
28
0
8
10
13
35
e
d
c
b
t
s
28
8
10
13
35
d
c
b
t
s
28
8
10
13
35
d
c
b
t
s
25
5
10
10
05
d
c
b
t
s
25
5
10
10
5
d
c
b
t
s
25
5
10
10
5
d
c
b
t
s
20
0
10
10
0
d
c
b
t
s
20
10
10
d
c
b
t
0
0
0
c
b
10
s
20
10
10
d
c
b
t
10
s
10
10
10
c
b
t
s
10
10
10
c
b
t
10
10
10
c
b
t
0
s a t60 15
=15d20
s a t45 17
=1730
c
s a t28 28
=2850
e
s b t50 22
=2222
e
s b c28 8
=3
3
d t13
s b t25 5
=55
d
s b20 10
=10t
s b t10 10
=1010
c
Loss of Line B-D• Load at bus D must be
reduced from 20 to 15• Load at bus C must be
reduced from 30 to 27
Outline
• FACTS Devices
• Max Flow
• Suitability of Max Flow to Power System
• Distributed Max Flow
• Fault Tolerance of Distributed Max Flow
Suitability of Transportation Model (max flow)to Power
Systems?• Losses and Reactive Power?
• Experimental Verification– No difference at steady state from max flow– A few percent difference between max flow
calculations and load-flow analysis after a contingency using FACTS devices
• In general, lines are not all maximally loaded. The power flow can then be re-directed to new transmission corridors.– Where re-direct?– How much to re-direct?– How account for KCL?– Control/communication between decision-
making devices?
Placement of FACTS Devices• Experimentally:
1. Delete a line2. Run Max Flow servicing loads increasing line
capacities by reverse augmentation to a maximum of 20%.
3. Using Load Flow analysis, place FACTS devices to eliminate overloaded lines.
4. Go to step 1
Placement of FACTS Devices
Resulting System Configuration
Resulting Line Overloads (>20%)actual max base w/o %
flow FACTS
37 38 30 38 -0.7466 -0.5849 0.5849 -0.8791 27%46 47 47 49 0.1323 0.0838 -0.0838 0.1904 58%47 69 47 49 -0.3434 -0.1006 -0.0838 -0.5420 290%60 61 60 62 -0.7354 -0.1217 -0.1014 -0.8822 605%77 80 69 77 0.9940 0.7144 0.5953 0.8951 47%80 96 96 97 -0.1965 -0.1051 -0.0914 -0.1432 100%
Line Out MaximumOverload
Outline
• FACTS Devices
• Max Flow
• Suitability of Max Flow to Power System
• Distributed Max Flow
• Fault Tolerance of Distributed Max Flow
Distributed Max flow
• Multiple source (generator)• Concurrent flow-augmenting probes• FACTS devices communicate by message passing
along the direction of the flow augmentation• Each FACTS device computes the flow for a
partition of lines (using Chaco from Sandia)• Multiple Computers, Open Communication Lines,
Distributed Software
Outline
• FACTS Devices
• Max Flow
• Suitability of Max Flow to Power System
• Distributed Max Flow
• Fault Tolerance of Distributed Max Flow
Vulnerabilities
• Computer System Failure
• Programming Errors
• Hackers (Security Intrusions)
Software Correctness?
• Distributed Computing System– Verification (Development Time)?
• Complexity– Model Checking and Theorem Proving
– Testing• Test Cases
– Monitoring• Assertion Testing.
Proposed Idea
Combine assertions from
formal verification with run-time checking (monitoring).
Proposed Approach
• Distributed run-time assertion checking – focuses on the unique execution in progress -
guarantees that the current execution meets its specifications regardless of underlying hardware or system confidence
Embedded Monitoring
• Assertions are predicates are a collected global state of events
• If an event happens before another they can be partially ordered
• Lamport Logical Clock– Each event has a logical timestamp C[event]– The most current event is the one with the largest
timestamp.– Timestamps are forced to increase on a message receive so
that message sends precede message receives.
Underlying Theory• Correctness is defined by theorems about the program. Theorems
are easily translated into assertions for monitoring.• For the assertions to be correct, a program code action, a, must not
interfere with the truth of an assertion, P (<P & pre(a)> a <P>).
• In a distributed system, this truth must be preserved over all interleavings of processes.
• Using timestamps, the monitoring is guaranteed to correctly reflect the distributed program’s state.
Failure Scenario
• Distributed Multiple Source Max Flow
• Correctness is defined by KCL at each node
• FACTS devices B and C faulty
• Attempt to Overload line B-C (flow=20)
Failure Scenario100
40
17
28
50
50
22
815
10
30
320
s
a
e
d
c
b
t
Push Flow to A&B, B finds C blocked.
10
83
40
28
50
10
22
815
13
320
s
a
e
d
c
b
t
Push Flow to A&B
10
10
B Can Augment Flow to t.83
40
28
50
10
22
815
17
320
s
a
e
d
c
b
t
Push Flow to A&B
20
B Can Augment Flow to t
B Incorrectly Overloads Arc to C with 20,Node C tries to hide, as well, And augments flow C-t as 17
10
Before B’s Probe Returns, A augments through D.Since the path is full, D receives a blocked message, carrying C’s sum of 7
t
83
40
28
50
22
815
13
320
s
a
e
d
c
b
Push Flow to A&B
20
B Augments Flow to t, instead.
B Incorrectly Overloads Arc to C with 20,Node C tries to hide, as well, And augments flow C-t as 13
10
10
System Framework
Informal Specification
Security and Functional
Requirements
Formal Code
Operational Evaluation
System OK or
Specification ViolationIntruders
Failures
Interpretation Refinement
Verification
Status and Results
• Simple Max Flow is an effective formalism to balance power flow
• Detects Faults• Need to measure performance and fault
tolerance levels.• Real-Time algorithm needs to respond
before cascading failure occurs.