Synthesis of software-based protocols for dynamically reconfigurable - - PowerPoint PPT Presentation

synthesis of software based protocols for dynamically
SMART_READER_LITE
LIVE PREVIEW

Synthesis of software-based protocols for dynamically reconfigurable - - PowerPoint PPT Presentation

Synthesis of software-based protocols for dynamically reconfigurable networks Ufuk Topcu (Univ of Pennsylvania) www.seas.upenn.edu/~UTopcu Outline: Reconfiguration in electric power networks on aircraft An academic testbed Newer


slide-1
SLIDE 1

Synthesis of software-based protocols for dynamically reconfigurable networks

Ufuk Topcu (Univ of Pennsylvania)

www.seas.upenn.edu/~UTopcu

Collaboration with Murray, Ozay, Xu (Caltech), Rogersten (KTH) and Wang (UPenn) References: CDC ’12, IEEE TII ’13 (review), HSCC ’13, CDC ’11

Outline:

  • Reconfiguration in electric power networks on aircraft
  • An academic testbed
  • Newer thoughts: reconfiguration in software-based networks
slide-2
SLIDE 2

Ufuk Topcu, UPenn

More-electric aircraft

Electrically powered systems (rather than pneumatically or hydraulically)

  • air conditioning & cabin pressurization
  • brakes & landing gear
  • wing ice protection

0.375 0.75 1.125 1.5 B767 A330 A340 A380 B787

power generation capacity (MVA)

Data: Frost & Sullivan (2008)

Challenges:

  • Safety-critical electric power system
  • Distributed architectures
  • Increased complexity

Opportunities:

  • More efficient
  • Less power off-takes from engines
  • Lower losses due to transfer
  • Right function at the right time
  • Weight reductions
  • Electrical systems heavier than

conventional counterparts

  • System-level power and energy
  • ptimization is key.

Picture from: www.ece.cmu.edu/~electriconf/2008/PDFs/Karimi.pdf

Power Distribution and Conversion

Gen

Power Electronics

Power Distribution and Conversion Fan Controllers

Power Electronics Cooling Systems

Flight Control Actuators Avionics-IFE Electric Brakes WIPS

Gen Gen

Power Electronics

Cabin Air Compressor Electric Driven Hydraulic Pumps

Power Electronics

787 has a total of 1 MW of Power Electronics Loads

2

slide-3
SLIDE 3

Ufuk Topcu, UPenn

Single-line diagram -- electric power distribution

  • Generation
  • Engines
  • APUs
  • External power
  • Buses
  • AC vs DC
  • Essential vs non-essential
  • High vs low voltage
  • Loads
  • Contactors
  • Transformers
  • Rectifier units

generators high-voltage AC buses high-voltage DC buses low-voltage AC buses low-voltage DC buses transformers rectifier units contactors

Figure adapted from US Patent 7439634 B2 by Rich Poisson (UTAS)

slide-4
SLIDE 4

Ufuk Topcu, UPenn

Dynamic reconfiguration

Reconfigure the network by opening and/or close the contactors

4

APU

HVAC Bus 2 HVAC Bus 3

E

HVAC Bus 4

ENGINE 1

HVAC Bus 1

L L Ls Ls

Start Bus 1

HVRU 1 HVRU 2

HVDC Bus 1

HVRU 3 HVRU 4

HVDC Bus 2

Motor Drive Motor Drive Motor Drive Motor Drive

Start Bus 2

ESS Motor Drive ESS Motor Drive ESS Motor Drive ESS Motor Drive

BAT2 BAT1

in reaction to the changes in the environment

  • health status of the

components

  • flight phase
  • pilot requests

to satisfy safety and performance specifications.

×

slide-5
SLIDE 5

Ufuk Topcu, UPenn

APU

HVAC Bus 2 HVAC Bus 3

ENGINE 1

HVAC Bus 1

L Ls

Start Bus 1

HVRU 1 HVRU 2 HVRU 3

S

BAT1

Sample specifications

No AC bus shall be simultaneously powered by more than one AC source Buses shall be powered according to their priority tables Essential AC buses shall never be unpowered more than 50 msec Do not exceed the capacity of the generator Do not lose more than one bus for single failure Requirements: Bounds on the number and sequence of contactor switchings Assumptions: Known reliability of components Worst-case bounds on contactor switching times Typical failure modes to react to

slide-6
SLIDE 6

Ufuk Topcu, UPenn

Abstract Model

Single Line Diagram +

Formal Specifications

Temporal Logic

TuLiP

Python-based toolbox for automatic controller synthesis

Software Models

Simulink + Power Systems Toolbox

Hardware Implementation

Single-line diagram for the testbed

6

Workflow

slide-7
SLIDE 7

Ufuk Topcu, UPenn

Formal specifications (a subset of them)

7

B3! B4! C4! C7! C5! C6! B1! B2! G1! C1! C2! C3! G2! G3! G4!

Always open contactors neighboring an unhealthy generator Requirements: No paralleling

“Flow direction” through contactor

Buses are powered only if connected to a healthy generator or a powered bus Bounded duration of “unpoweredness” of essential buses -- introduce a clock Assumptions: At least one of the generators is always healthy

slide-8
SLIDE 8

Ufuk Topcu, UPenn

8

Find: A map F such that realizes the specification.

Reactive synthesis as a two-player temporal logic game

  • utput,

s = (p,e)

environment,

e

Controlled variables, p

F

Given:

  • Environment (e) and controlled (p) variables over finite domains
  • Temporal logic specification =

ϕ(e, p)

ϕe → ϕs

Can be formulated as a game between the environment and the system.

slide-9
SLIDE 9

Ufuk Topcu, UPenn

9

Find: A map F such that realizes the specification.

Reactive synthesis as a two-player temporal logic game

  • utput,

s = (p,e)

environment,

e

Controlled variables, p

F

Solving the game:

  • Intractable for general LTL
  • Polynomial complexity for GR[1]

specifications

[Piterman et al., 2007&2011]

{

{ {

initial conditions safety + transitions fairness + goals (always) (always eventually) Given:

  • Environment (e) and controlled (p) variables over finite domains
  • Temporal logic specification =

ϕ(e, p)

ϕe → ϕs

θα

init ^

^

i∈Kα

⇤ψα

i ^

^

i∈Lα

⇤ ⇧ Jα

i

Both sides are of the form ( ):

ϕα =

α ∈ {e, s}

slide-10
SLIDE 10

Ufuk Topcu, UPenn

!"#$%&'%(%)*%% &+%(%)*%,%

  • ./$%0)%(%)*%%

01%(%),%% !"#$%&'%(%2*%% &+%(%2*%,%

  • ./$%0)%(%2*%%

01%(%2,%% !"#$%&'%(%)*%% &+%(%2*%,%

  • ./$%0)%(%)*%%

01%(%2,%% !"#$%&'%(%2*%% &+%(%)*%,%

  • ./$%0)%(%2*%%

01%(%),%% !"#$%&'%(%2*%% &+%(%2*%,%

  • ./$%0)%(%2*%%

01%(%2,%% !"#$%&'%(%)*%% &+%(%)*%,%

  • ./$%0)%(%)*%%

01%(%),%%

  • 3435%)%
  • 3435%6%
  • 3435%7%
  • 3435%8%
  • 3435%9%
  • 3435%1%

Automaton representation:

10

Structure of the controller

B3! B4! C4! C7! C5! C6! B1! B2! G1! C1! C2! C3! G2! G3! G4!

f : (s0s1 . . . st, et+1) 7! pt+1

e: health status of the generators p: contactor status & bus powered

Strategy:

s = (e, p)

slide-11
SLIDE 11

Ufuk Topcu, UPenn

A sample simulation -- sanity check

11

Given arbitrary, admissible environment signals, read the system

  • utputs from the automaton
slide-12
SLIDE 12

Ufuk Topcu, UPenn

12

Overview of testbed functionality

slide-13
SLIDE 13

Ufuk Topcu, UPenn

13

rectifier unit power sources switchboard, i.e., contactors AC load AC load DC loads connection to controller sensing circuitry + more cables switches to induce transformer failures

A look of the testbed

slide-14
SLIDE 14

Ufuk Topcu, UPenn

14

Hardware tests -- normal operation

AC generator fault fault controller reacts generator

  • n again
slide-15
SLIDE 15

Ufuk Topcu, UPenn

15

Hardware tests -- environment assumptions violated

“next” controlled variable value is assigned

!"#$%&'%(%)*%% &+%(%)*%,%

  • ./$%0)%(%)*%%

01%(%),%% !"#$%&'%(%2*%% &+%(%2*%,%

  • ./$%0)%(%2*%%

01%(%2,%% !"#$%&'%(%)*%% &+%(%2*%,%

  • ./$%0)%(%)*%%

01%(%2,%% !"#$%&'%(%2*%% &+%(%)*%,%

  • ./$%0)%(%2*%%

01%(%),%% !"#$%&'%(%2*%% &+%(%2*%,%

  • ./$%0)%(%2*%%

01%(%2,%% !"#$%&'%(%)*%% &+%(%)*%,%

  • ./$%0)%(%)*%%

01%(%),%%

  • 3435%)%
  • 3435%6%
  • 3435%7%
  • 3435%8%
  • 3435%9%
  • 3435%1%

Both transformers become unhealthy simultaneously---violating an assumption---and the controller cannot assign a “next” value for the controlled variables.

slide-16
SLIDE 16

Ufuk Topcu, UPenn

16

Limitations and lessons

Sensing and perception are important and often ignored.

  • Matching the sensing modalities in theory and practice
  • Limitations in sensing
  • Uncertainties in perception

Have mostly ignored the underlying dynamics

  • Seems to work fine at this level of detail
  • In general, need for hierarchical control

APU

HVAC Bus 2 HVAC Bus 3

ENGINE 2

HVAC Bus 4

ENGINE 1

HVAC Bus 1

L L Ls Ls

Start Bus 1

HVRU 1 HVRU 2

HVDC Bus 1

HVRU 3 HVRU 4

HVDC Bus 2

Motor Drive Motor Drive C1

B1

Motor Drive Motor Drive

B2

C2

Start Bus 2

ESS Motor Drive ESS Motor Drive

A1

A2 ESS Motor Drive ESS Motor Drive A4

A3

BAT2 BAT1

Controller structure is key for...

  • Reliability
  • Scalability

Have ignored most of the hard timing constraints

slide-17
SLIDE 17

Ufuk Topcu, UPenn

17

Compositional synthesis of distributed protocols

∧iϕei → ϕe → ϕs → ∧iϕsi

}

“weaker” environment assumptions

}

“stronger” system requirements Extra (mild) technical conditions: No common controlled variables & loops are well-posed.

Fact: is realizable if every is realizable.

ϕe → ϕs ϕei → ϕsi

S1 S2 S3 K1

K2 K3

ϕe1 → ϕs1 ϕe3 → ϕs3

ϕe2 → ϕs2

Contracts formalize information exchange,...

  • design-time---between the design teams---and
  • run-time---between the subsystems.

controlled subsys local controller physical coupling information flow exogenous signal

slide-18
SLIDE 18

Ufuk Topcu, UPenn

18

Distributed controllers for the power network

B3! B4! C4! C7! C5! C6! B1! B2! GL! C1! C2! C3! AL! AR! GR! SYS1! SYS2! Health Status !

(of SYS1 generators)!

Power!

Master (SYS2) / Slave (SYS1):

  • Uni-directional power flow

(SYS2 → SYS1)

  • Assume always AR or GR healthy
  • SYS2 sees the health status of SYS1
  • Make B3 an essential bus

Decentralized:

  • Bi-directional power flow
  • Restrictions to avoid deadlock
  • Make B2 and B3 an essential bus
  • Additional assumptions on both sides

⇤(GL = 0 ∧ AL = 0 → C4 = −1) ⇤(GR = 0 ∨ GL = 0 ∨ B2 = 1)

slide-19
SLIDE 19

Ufuk Topcu, UPenn

19

Application to the testbed

Specifications naturally decompose into AC and DC parts. assumptions: non-paralleling of AC buses: strict timing constraints: Assume: Rectifier units have capacitors that can power the DC buses for some time T>0 and generators stay healthy (once they become) for longer than T. Impose extra assumption on DC side: ⇤(ru1 = healthy ∧ ru2 = healthy)

→ ⇤(bDC1 = powered ∧ bDC2 = powered)

slide-20
SLIDE 20

Ufuk Topcu, UPenn

Specialized Packet Forwarding Hardware

App App App

Operating System Specialized Packet Forwarding Hardware

App App App

Operating System Specialized Packet Forwarding Hardware

App App App

Operating System Specialized Packet Forwarding Hardware Operating System

App App App

Specialized Packet Forwarding Hardware Operating System

App App App

Specialized Packet Forwarding Hardware Operating System

App App App

Specialized Packet Forwarding Hardware Operating System

App App App

Specialized Packet Forwarding Hardware Operating System

App App App

Specialized Packet Forwarding Hardware Operating System

App App App 20

Software-defined networking (SDN)

Traditional networks

  • Limited intelligence, implemented as

routing protocols

  • Integrated control plane and data plane
  • Hard to manage or change
slide-21
SLIDE 21

Ufuk Topcu, UPenn

20

Software-defined networking (SDN)

Traditional networks

  • Limited intelligence, implemented as

routing protocols

  • Integrated control plane and data plane
  • Hard to manage or change

Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware

App App App

Simple Packet Forwarding Hardware

Network Operating System

Controller box/cluster Open interface to hardware (e.g. OpenFlow) Software-defined networks

  • Control plane is separated from data

plane

  • Centralized (to certain extent)
  • Hard to scale & reason about
slide-22
SLIDE 22

I F1 F2 F3 Type Action I U, G S F Forward F1 Forward F2 Forward F3 F1 SSH * Deny Allow F2 * Allow F3 * Allow Type Action I U G S, F Forward F1 Forward F2 Forward F3 F1 SSH * Deny Allow F2 SSH * Deny Allow F3 * Allow

A synthesis problem in SDN

Configuration migration: Update the forwarding rules Constraints: Enforce a security policy that denies SSH traffic from untrustworthy hosts, but allows all other traffic to pass through the network Synthesize ordering of rule updates

21

Ufuk Topcu, UPenn

Simply a closed-system synthesis question -- use nuSMV to obtain:

  • Update I to forward S traffic to F3
  • Update F2 to deny SSH packets
  • Update I to forward G traffic to F2
slide-23
SLIDE 23

Ufuk Topcu, UPenn

22

  • Switches: I(ingress), F1,2 (switches for two servers)
  • Flows: U(untrusted), G(guest), S(student), F(faculty)
  • High-level policy for U flows: monitor SSH packets, deny all other

I F1 F2

F : Forward to F2 S : Forward to F1 U : Forward to F1 G : Forward to F1 U: Monitor SSH U: Deny other G: Monitor SSH G: Deny other S: Allow all F: Allow all

Flows: U,G,S,F

F : Forward to F2 S: Forward to F1 U: Forward to F2 G: Forward to F1

I F1 F2

Flows: U,G,S,F

Access control reconfiguration

Same as configuration migration with updates chosen by users, e.g., to balance loads Hence, need to treat the updates as adversarial inputs from environment

? ?

slide-24
SLIDE 24

Ufuk Topcu, UPenn

23

F : Forward to F2 S: Forward to F1 U: Forward to F1 U: Forward to F2 G: Forward to F1 U: Monitor SSH U: Deny other G: Monitor SSH G: Deny other S: Allow all F: Allow all U: Monitor SSH U: Deny other

I F1 F2

Flows: U,G,S,F F1ac: Deny, F2ac: Deny, Iac: Deny, IF: 1 1; F1ac: Deny, F2ac: Allow, Iac: Allow, IF: 1 2; F1ac: Deny, F2ac: Deny, Iac: Allow, IF: 2 IF=1 IF= 1 IF=1 IF=2 IF=2 IF=2 F1ac: Deny, F2ac: Allow, Iac: Allow, IF: 1 F1ac: Deny, F2ac: Deny, Iac: Allow, IF: 2 IF=2

A toy example for access control reconfiguration

Part of the resulting automaton Updates in access control

slide-25
SLIDE 25

Ufuk Topcu, UPenn

24

Flows: U,G,S,F

I F1 F2

Flows: U,G,S,F I F2 F1

Access control reconfiguration using a topology-based abstraction

slide-26
SLIDE 26

Ufuk Topcu, UPenn

24

Flows: U,G,S,F

Access control reconfiguration using a topology-based abstraction

slide-27
SLIDE 27

Ufuk Topcu, UPenn

24

Flows: U,G,S,F

Access control reconfiguration using a topology-based abstraction

F1ac: Deny? F2ac: Deny? IF:2, Iac:Allow?

slide-28
SLIDE 28

Ufuk Topcu, UPenn

24

Flows: U,G,S,F

Access control reconfiguration using a topology-based abstraction

IF4:2, Iac4:Allow Iac3: Allow Iac2: Allow Iac1: Allow Allow Deny Allow Allow Allow Allow Allow Deny

slide-29
SLIDE 29

Ufuk Topcu, UPenn

25

Interactions with software-defined networking

Lessons from networking on making progress in scalability? Relatively well-established notions of network abstractions

  • based on topology
  • based on flow properties/predicates, e.g., bandwidth

Property-preserving decompositions

  • virtual networks
  • slide isolation