Fault-Tolerant and Secure Intelligent Vehicle Highway System Software - a Safety Prototype

1
Distributed Control of FACTS Devices Using a
TransportationModel
Bruce McMillin Computer Science Mariesa
Crow Electrical and Computer Engineering Universi
ty of Missouri-Rolla Rolla, MO 65409-0040
2
Outline

• FACTS Devices
• Max Flow
• Suitability of Max Flow to Power System
• Distributed Max Flow
• Fault Tolerance of Distributed Max Flow

3
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

4

• FACTS devices offer a decentralized
  network-embedded control mechanism

5
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

6
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

7
Outline

• FACTS Devices
• Max Flow
• Suitability of Max Flow to Power System
• Distributed Max Flow
• Fault Tolerance of Distributed Max Flow

8
Example
9
(No Transcript)
10
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.

11
10
12
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

13
Outline

• FACTS Devices
• Max Flow
• Suitability of Max Flow to Power System
• Distributed Max Flow
• Fault Tolerance of Distributed Max Flow

14
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

15

• 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?

16
Placement of FACTS Devices

• Experimentally
• Delete a line
• Run Max Flow servicing loads increasing line
  capacities by reverse augmentation to a maximum
  of 20.
• Using Load Flow analysis, place FACTS devices to
  eliminate overloaded lines.
• Go to step 1

17
Placement of FACTS Devices
18
Resulting System Configuration
19
Resulting Line Overloads (gt20)
20
Outline

• FACTS Devices
• Max Flow
• Suitability of Max Flow to Power System
• Distributed Max Flow
• Fault Tolerance of Distributed Max Flow

21
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

22
Outline

• FACTS Devices
• Max Flow
• Suitability of Max Flow to Power System
• Distributed Max Flow
• Fault Tolerance of Distributed Max Flow

23
Vulnerabilities

• Computer System Failure
• Programming Errors
• Hackers (Security Intrusions)

24
Software Correctness?

• Distributed Computing System
• Verification (Development Time)?
• Complexity
• Model Checking and Theorem Proving
• Testing
• Test Cases
• Monitoring
• Assertion Testing.

25
Proposed Idea
Combine assertions from formal verification with
run-time checking (monitoring).
26
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

27
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 Cevent
• 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.

28
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
• (ltP pre(a)gt a ltPgt).
• 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 programs
  state.

29
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 (flow20)

30
Failure Scenario
31
System Framework
32
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.