Standards for Autonomous and Secure Microgrids

Duke Energy Emerging Technology Office

Standards for Autonomous and Secure Microgrids

Stuart Laval

3/18/2015 page 3Copyright © 2015 Duke Energy All rights reserved.

About Duke Energy

• One of the Largest Electric Holding Companies in the United States

• Electric Utility operations in North and South Carolina, Indiana, Ohio, Kentucky and Florida serving 7.2 million customers

• 57,500 MW of regulated generation

• Renewable generation of 1500 MW of wind and 200 MW of solar located throughout the United States

Copyright © 2015 Duke Energy Corporation All rights reserved. page 4

History of Duke Energy Smart Grid Developments

• (~2007) Initially, we focused on the problem of connecting to multiple devices to backhaul data.

– Node-based solution (high volume) with multiple radios to connect to MV sensors, AMI, DA, and others.

• (~2012) But use cases evolved and new technologies (battery storage, microgrids, etc.) drove need to get access to data cheaper/better/faster at the edge of the network.

– Drove need for node platform hosting 1 or more standards-based message busses and common semantic models.

Copyright © 2015 Duke Energy Corporation All rights reserved.

Duke Energy Test Areas: Integrated Grid Ecosystems Pilot (2012)

Sub

stat

ion • Solar PV

• Energy Storage• Dist. Mgmt System• PMU (6)• Weather stations (7)

Sher

rill’

s Fo

rd, R

anki

n,

McA

lpin

eSu

bst

atio

ns

Cu

sto

me

rP

rem

ise

~60

ho

mes

ser

ved

by

M

cAlp

ine

circ

uit

s • Solar PV• Home Energy Manager• PEV • Charging Stations• Smart Appliances• Demand Response • In-home load monitoring

Dis

trib

uti

on

C

ircu

it

6 M

cAlp

ine

circ

uit

s

• Line Sensors (200+)• Solar PV• CES, HES Energy Storage • Comm. Nodes (3,000)• Intelligent Switches• DERMS/DMS• AMI metering (14,000)

3/18/2015 page 6Copyright © 2015 Duke Energy All rights reserved.

Key Observations:1. Multi-Purpose Functions2. Modular & Scalable HW&SW3. End-to-End Situational Awareness4. OT/IT/Telecom Convergence5. True Field Interoperability!

Key Observations:1. Single-Purpose Functions2. Proprietary & Silo’ed systems3. Latent , Error-prone Data4. OT/IT/Telecom Disconnected5. No Field Interoperability!

Lessons Learned from 2012 Smart Grid Pilot

Copyright © 2015 Duke Energy Corporation. All rights reserved.

IPNetwork

3/18/2015 page 8

Smart Meter

Capacitor Bank

LineSensor

XStreet Light

SmartAssets

DistributedEnergy Resources

Transformer

Intelligent Switch

DEM

AN

DEL

ECTR

IC G

RID

Smart Generation

Continuous Emission Monitoring

Weather SensorSUP

PLY

Other Nodes

Open StandardsNode

CPU

Radio InternetConnectivity

Distributed Intelligence

HeadEnd A

HeadEnd B

HeadEnd N

Data C

en

ter Message B

us

Network Router

UTILITYDATA CENTER

“Internet of Things” Platform for the Utility

Copyright © 2015 Duke Energy All rights reserved.

Technology Approach1. Internet Protocol2. Translation3. Contextualization4. Security5. Analytics

Open Field Message Bus (OpenFMB)

IPNetwork

3/18/2015 page 9

Smart Meter

Capacitor Bank

LineSensor

XStreet Light

SmartAssets


Transformer

Intelligent Switch

DEM

AN

DEL

ECTR

IC G

RID

Smart Generation


Weather SensorSUP

PLY

Other Nodes

Open StandardsNode

Virtual OS

Core OS InternetConnectivity

Distributed Intelligence

HeadEnd A

HeadEnd B

HeadEnd N

Data C

en

ter Message B

us

Network Router

UTILITYDATA CENTER



Technology Approach1. Internet Protocol2. Translation3. Contextualization4. Security5. Analytics

Open Field Message Bus (OpenFMB)

IPNetwork

3/18/2015 page 10

Smart Meter

Capacitor Bank

LineSensor

XStreet Light

SmartAssets


Transformer

Intelligent Switch

DEM

AN

DEL

ECTR

IC G

RID

Smart Generation


Weather SensorSUP

PLY

Other Nodes

Open StandardsNode

HeadEnd A

HeadEnd B

HeadEnd N

Data C

en

ter Message B

us

Network Router

UTILITYDATA CENTER• Processor(s) + Memory

• Linux-based OS • Open API Messaging• 3rd Party Apps• Security / Network Mgr

4G LTE, Wi-Fi, GPS

Ethernet, Serial

PLC, RF ISM, Bluetooth

IP RouterCapabilities

OptionalConnectivity

Distributed Computing

I/O, Metrology, Fiber

OptionalRequired

Legend



Flexible Hardware & Software Platform

11

RetrofitInside Cabinet

Pole MountedEnclosure

PadmountEnclosure

SubstationRackmount Server(s)

Integrated in End Device(as Software)


AMISmart Meters

Protection& Control


IP Router

Virtual Software

Corporate Private

Network

MDM

SCADA

Headend

Higher Tier Central Office

(Utility Datacenter)

Application OS

Core OS

Legend

Middle TierNodes

(e.g. substation)

Lower TierNodes

(e.g. grid)

End PointsDevices

IP Router

Virtual Software

IP Router

Virtual Software

Field Area Network

(FAN)

Wide Area Network(WAN)

Local Area Network

(LAN)

Local Area Network

(LAN) Physical Transport

Virtual Telemetry

Tier 5 DIP Node

Firewall

Virtual Firewall

DMS

IoT Reference Architecture: Hybrid Multi-level Hierarchy

Copyright © 2015 Duke Energy Corporation All rights reserved.

OPEN APIMESSAGE BUS

Use-Case App(s)

OT System or Device

Analytics

Messaging

Translation

IT

Pu

blis

h

Sub

scri

be

Pu

blis

h

DNP Modbus

SmartMeter

CapBank

Intelligent Switch

FCI lineSensor

Sub

scri

be

OT

Compression

Security

Pu

blis

h

Sub

scri

be

Other

Pu

blis

h

Sub

scri

be

Transformer TelcoRouter

Battery/PVInverters

DMS PiSandbox

Head-End

Pu

blis

h

Sub

scri

be

Convergence of OT and IT

DDS, MQTT,AMQP


Enabling Distributed Energy Resources with Intelligence at the Edge

Current State – Centralized Decision-Making Future State – Distributed Decision-Making

Meter Sensor

Cellular Network

Utility Office

Battery Storage

Rapid Swing inProduction

Meter Line Sensor

Node

Cellular Network

Utility Office

Battery Storage

Rapid Swing inProduction

Update Model

ResponseDecision +

UpdateModel

ResponseDecision

>1 Min < 0.25 sec

TransformerTransformer

Line SensorHead End

Line SensorHead End

14

Solar PV Solar PV

“Pass-Thru” “Field Message Bus”


Field Test: Community Energy Storage

Shifting & Smoothing

In-rush Smoothing

Node w/ Field Msg Bus


Why use an Open Field Message Bus (OpenFMB)?

• Pub-Sub Advantages vs. Polling

• Standard Interfaces & Dictionary

• Flexibility & Resiliency

• Unlocks Modularity

• Scalable Infrastructure

• Organizational Efficiencies

page 16Copyright © 2015 Duke Energy All rights reserved.

Benefits of the OpenFMB Framework

• Customer Benefits

• Cost Savings

• Risk Mitigation


Strategies to Gain Adoption of OpenFMB

• Developed and Published Duke Energy Reference Architecture– http://www.duke-energy.com/pdfs/DEDistributedIntelligencePlatformVol01.pdf

• Standards strategy (2015)– SGIP– NAESB– UCAIug

• Getting utilities on board (2014-today)

• Getting vendors on board (2013-today)– Duke Energy Coalition of the Willing (part 1) – Distributech 2014 demo

(6 vendors)– Duke Energy Coalition of the Willing (part 2) – Distributech 2016 demo

(25+ vendors)Copyright © 2015 Duke Energy All rights reserved.

Duke Energy Test Microgrid Lab: Mount Holly, NC

PV Installations

Islanding Switch,

Transformer, and Battery

Behind the meter and low voltage power

electronic equipment

Grid Equipment


Why is the OpenFMB Important for Duke Energy?

page 20

• Provides accurate control and alleviates intermittency of distributed energy resources

• Provides the ability to scale independently, as needed, without needing a system wide rollout

• Takes cost out of the business by reducing integration time and effort

• Allows Duke to be at the forefront of developing new regulations and policies


Thank You!

For more information contact:

Stuart Laval, Duke [email protected]

page 21Copyright © 2015 Duke Energy All rights reserved.

Your systems. Working as one.

DDS: Connectivity Framework for Autonomous and Secure Microgrids

David Barnett

March 19, 2015

DDS: Designed for Critical Control Systems

• Real-time– Event-driven (push)– Low latency: sub-second, as low as μs– Often require determinism

• Always on– No unplanned downtime– No single point of failure or failover– Live upgrades

• Autonomous– Deployed at edge, in field (OT)– No run-time administration– Self-healing

• Extremely large scale– Up to millions of data and I/O points– Highly meshed– Millions or more updates/second

3/19/15 23© 2015 RTI

DDS: Designed for Critical Control Systems

• Real-time– Event-driven (push)– Low latency: sub-second, as low as μs– Often require determinism

• Always on– No unplanned downtime– No single point of failure or failover– Live upgrades

• Autonomous– Deployed at edge, in field (OT)– No run-time administration– Self-healing

• Extremely large scale– Up to millions of data and I/O points– Highly meshed– Millions or more updates/second

3/19/15 24© 2015 RTI

• Decentralized

• Intelligence at the edge

DDS Provides a Software Data Bus

Data Distribution Service

Sensors Actuators

Streaming Analytics &

ControlHMI

IT, Cloud & SoSConnectivity

3/19/15 © 2015 RTI 25

DDS is Decentralized, BrokerlessComponents Communicate Peer-to-Peer

Embedded library for new and updated apps

Adapter for existingapps and devices

3/19/15 26© 2015 RTI

DDS Interoperability Protocol

DDS App

DDS Library

DDS Device

DDS Library

OS & Transport OS & Transport

DDSAPI

Non-DDSApp

DDS Routing Service

Adapter

Non-DDSDevice

DDS Routing Service

Adapter


E.g.: DNP3, 61850

PhysicalNetwork

DDS Uses

• Native interface

• Fast, scalable, resilient and secure integration bus

• Uniform API to devices with disparate native interfaces

3/19/15 27© 2015 RTI

Canonical Data Model

DDS App

DDS Library

DDS Device

DDS Library


Non-DDSApp

DDS Routing Service

Adapter

Non-DDSDevice

DDS Routing Service

Adapter


E.g.: DNP3, 61850

Integrated Capabilities

3/19/15 28© 2015 RTI

Transport-Layer Protocol

Reliable Messaging

Discovery

Type System - Evolvable

Real-Time Data Management

Request/Reply

Re

al-Time

Qu

ality of Se

rvice

Secu

rity

Data-Centric Publish-Subscribe

Application or AdapterDDS API

DDS-RTPS Wire Protocol

Operating System


3/19/15 29© 2015 RTI

Transport-Layer Protocol(s)

Reliable Messaging

Discovery



Request/Reply

Re

al-Time

Qu

ality of Se

rvice

Secu

rity


Application or Adapter

Operating System

• Provides reliability at messaging and app layers

• No requirement for reliable transport or IP

• Supports unicast and multicast• Typical:

• LAN: UDP ucast & mcast• WAN: TCP/TLS

• Also supports shared memory, radio, satellite

• Supports multiple concurrent transports


3/19/15 30© 2015 RTI


Reliable Messaging

Discovery



Request/Reply

Re

al-Time

Qu

ality of Se

rvice

Secu

rity



Operating System

• High-level API abstracts apps from messaging details

• Apps read() and write() data objects

• Akin to using a database• Can poll for latest value or get

async notification of change• Subscriptions based on

content and time• DDS handles data distribution,

synchronization and filtering• Also flexible request/reply


3/19/15 31© 2015 RTI


Reliable Messaging

Discovery



Request/Reply

Re

al-Time

Qu

ality of Se

rvice

Secu

rity



Operating System

• DDS automatically discovers and connects matching publishers and subscribers

• Little or no configuration is required

• Systems are self-forming and self-healing


3/19/15 32© 2015 RTI


Reliable Messaging

Discovery



Request/Reply

Re

al-Time

Qu

ality of Se

rvice

Secu

rity



Operating System

• Rich built-in type system• Automatically serializes and

deserializes data• Uses compact, binary wire

representation• Most type metadata only

exchanged at discovery time• Types can evolve without

breaking backward compatibility


3/19/15 33© 2015 RTI


Reliable Messaging

Discovery



Request/Reply

Re

al-Time

Qu

ality of Se

rvice

Secu

rity



Operating System

• Control over:• Timing• Latency/throughput

tradeoffs• Level of reliability, from

best effort to durable storage with app-ack

• Failover• Resource utilization• History cache, including

for late joiners• Ordering

• Missed deadline notifications

DDS Security

• Configured at the DDS layer• Transparent to apps and adapters• Runs over any transport

– Including low bandwidth, unreliable– Multicast for scalability, low latency– Does not require TCP, (D)TLS or IP

• Plugin architecture– Built-in defaults– Customizable via standard API

• Completely decentralized– High performance and scalability– No single point of failure

Secure DDSlibrary

Authentication

Access Control

Encryption

Data Tagging

Logging

App / Adapter

Any Transport(e.g., TCP, UDP, multicast,

shared memory, )

3/19/15 © 2015 RTI 34

Standard Capabilities

Authentication X.509 Public Key Infrastructure (PKI) with a pre-configured shared Certificate Authority (CA)

Digital Signature Algorithm (DSA) with Diffie-Hellman and RSA for authentication and key exchange

Access Control Specified via permissions file signed by shared CA Control over ability to join systems, read or write data topics

Cryptography Protected key distribution AES128 and AES256 for encryption HMAC-SHA1 and HMAC-SHA256 for message authentication

and integrity Data Tagging Tags specify security metadata, such as classification level

Can be used to determine access privileges (via plugin)Logging Log security events to a file or distribute securely over

Connext DDS

3/19/15 © 2015 RTI 35

Control over Encryption

• Scope

– Discovery data

– Metadata

– Data

• For each:

– Encrypt

– Sign

• Optimizes performance by only encrypting data that must be private

3/19/15 © 2015 RTI 36

Overcomes Limitations ofTransport Layer Security

• No inherent access control– Usually implemented centrally

• No multicast support – Inefficient for broad data distribution

• Usually runs over TCP– Poor latency and jitter

– Requires a network robust enough to support IP and TCP

• All data treated as reliable– Even fast changing data that could be “best effort”

• Always encrypts all data, metadata & protocol headers– Even if some data does not have to be private

3/19/15 37© 2015 RTI

DDS Security Status

• Specification adopted March 2014

– Considered “Beta” for ~1 year

– RTI chairing Finalization Task Force

• Early Access Release available now from RTI

3/19/15 © 2015 RTI 38

Managed by Object Management Group

• ~300 member organizations

• Also manage UML, others

• Standards are freely available

– http://www.omg.org/spec/index.htm#DDS

• Open and formal process

– Anyone can join, contribute and vote

3/19/15 39© 2015 RTI

Broad Adoption and Support

• Used by at least 2,000 projects

• ~14 implementations

• 9 have demonstrated interoperability

3/19/15 © 2015 RTI 40

DDS Summary

• High performance and scalability– Decentralized architecture: no brokers as bottlenecks

– Peer-to-peer communication over multicast for low latency

– Wire and CPU efficient

• Reliable and autonomous– No single point of failure

– Support for redundant networks

– Automatic failover between redundant publishers

– Dynamic upgrades and data type evolution

– Self-healing

• Security without compromising operational requirements

3/19/15 41© 2015 RTI

About RTI

• Communications middleware market leader– Largest embedded middleware vendor– Over 70% commercial DDS market share

• Standards leader– Active in 15 standards efforts– DDS authors– OMG Board of Directors– Industrial Internet Consortium

• Maturity leader– 800+ commercial designs– 400+ research projects

*Embedded Market Forecastersand Venture Development Corp (VDC)

423/19/15 © 2015 RTI

Next Steps – Learn More

• Contact RTI– Demo, Q&A

• Download software– www.rti.com/downloads

– Free trial with comprehensivetutorial

– RTI Shapes Demo

• Watch videos & webinars, read whitepapers– www.rti.com/resources

– www.youtube.com/realtimeinnovations

3/19/15 © 2015 RTI 43

Audience Q & A

Stuart Laval,

Manager of Technology Development,

Duke Energy

David Barnett,

Vice President of Products and Markets,

RTI

Thanks for joining us

Event archive available at:

http://ecast.opensystemsmedia.com/

E-mail us at: [email protected]

Standards for Autonomous and Secure Microgrids

Software

Transcript of Standards for Autonomous and Secure Microgrids