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)
Substation
• Solar PV
• Energy Storage
• Dist. Mgmt System
• PMU (6)
• Weather stations (7)
Sherrill’sFord,Rankin,
McAlpineSubstations
Customer
Premise
~60homesservedby
McAlpinecircuits
• Solar PV
• Home Energy Manager
• PEV
• Charging Stations
• Smart Appliances
• Demand Response
• In-home load monitoring
Distribution
Circuit
6McAlpine
circuits
• 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 Functions
2. Modular & Scalable HW&SW
3. End-to-End Situational Awareness
4. OT/IT/Telecom Convergence
5. True Field Interoperability!
Key Observations:
1. Single-Purpose Functions
2. Proprietary & Silo’ed systems
3. Latent , Error-prone Data
4. OT/IT/Telecom Disconnected
5. No Field Interoperability!
Lessons Learned from 2012 Smart Grid Pilot
Copyright © 2015 Duke Energy Corporation. All rights reserved.

IP
Network
3/18/2015 page 8
Smart Meter
Capacitor Bank
Line
Sensor
XStreet Light
Smart
Assets
Distributed
Energy
Resources
Transformer
Intelligent Switch
DEMANDELECTRICGRID
Smart Generation
Continuous
Emission
Monitoring
Weather Sensor
SUPPLY
Other Nodes
Open Standards
Node
CPU
Radio Internet
Connectivity
Distributed
Intelligence
Head
End A
Head
End B
Head
End N
DataCenterMessageBus
Network
Router
UTILITY
DATA CENTER
“Internet of Things” Platform for the Utility
Copyright © 2015 Duke Energy All rights reserved.
Technology Approach
1. Internet Protocol
2. Translation
3. Contextualization
4. Security
5. Analytics
Open Field Message Bus
(OpenFMB)

IP
Network
3/18/2015 page 9
Smart Meter
Capacitor Bank
Line
Sensor
XStreet Light
Smart
Assets
Distributed
Energy
Resources
Transformer
Intelligent Switch
DEMANDELECTRICGRID
Smart Generation
Continuous
Emission
Monitoring
Weather Sensor
SUPPLY
Other Nodes
Open Standards
Node
Virtual OS
Core OS Internet
Connectivity
Distributed
Intelligence
Head
End A
Head
End B
Head
End N
Network
Router
UTILITY
DATA CENTER
Technology Approach
1. Internet Protocol
2. Translation
3. Contextualization
4. Security
5. Analytics
Open Field Message Bus
(OpenFMB)

IP
Network
3/18/2015 page 10
Smart Meter
Capacitor Bank
Line
Sensor
XStreet Light
Smart
Assets
Distributed
Energy
Resources
Transformer
Intelligent Switch
DEMANDELECTRICGRID
Smart Generation
Continuous
Emission
Monitoring
Weather Sensor
SUPPLY
Other Nodes
Open Standards
Node
Head
End A
Head
End B
Head
End N
Network
Router
UTILITY
DATA 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 Router
Capabilities
Optional
Connectivity
Distributed
Computing
I/O, Metrology, Fiber
Optional
Required
Legend

Flexible Hardware & Software Platform
11
Retrofit
Inside
Cabinet
Pole Mounted
Enclosure
Padmount
Enclosure
Substation
Rackmount Server(s)
Integrated in
End Device
(as Software)

AMI
Smart
Meters
Protection
& Control
Distributed
Energy
Resources
IP Router
Virtual
Software
Corporate
Private
Network
MDM
SCADA
Head
end
Higher Tier
Central Office
(Utility Datacenter)
Application OS
Core OS
Legend
Middle Tier
Nodes
(e.g. substation)
Lower Tier
Nodes
(e.g. grid)
End Points
Devices
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 API
MESSAGE BUS
Use-Case App(s)
OT System
or Device
Analytics
Messaging
Translation
IT
Publish
Subscribe
Publish
DNP Modbus
Smart
Meter
Cap
Bank
Intelligent
Switch
FCI line
Sensor
Subscribe
OT
Compression
Security
Publish
Subscribe
Other
Publish
Subscribe
Transformer Telco
Router
Battery/PV
Inverters
DMS PiSandbox
Head-End
Publish
Subscribe
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 in
Production
Meter Line Sensor
Node
Cellular Network
Utility Office
Battery
Storage
Rapid Swing in
Production
Update
Model
Response
Decision +
Update
Model
Response
Decision
>1 Min < 0.25 sec
TransformerTransformer
Line Sensor
Head End
Line Sensor
Head 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)

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 Energy
Stuart.Laval@duke-energy.com
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 &
Control
HMI
IT, Cloud & SoS
Connectivity
3/19/15 © 2015 RTI 25

DDS is Decentralized, Brokerless
Components Communicate Peer-to-Peer
Embedded library for
new and updated apps
Adapter for existing
apps and devices
3/19/15 26© 2015 RTI
DDS Interoperability Protocol
DDS App
DDS Library
DDS Device
DDS Library
OS & Transport OS & Transport
DDS
API
Non-DDS
App
DDS Routing
Service
Adapter
Non-DDS
Device
DDS Routing
Service
Adapter
E.g.: DNP3, 61850
Physical
Network

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-DDS
App
DDS Routing
Service
Adapter
Non-DDS
Device
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
Real-TimeQualityofService
Security
Data-Centric Publish-Subscribe
Application or Adapter
DDS API
DDS-RTPS Wire Protocol
Operating System

3/19/15 29© 2015 RTI
Transport-Layer Protocol(s)
Reliable Messaging
Discovery
Real-Time Data
Management
Request/Reply
Security
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
Real-Time Data
Management
Request/Reply
Security
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
Real-Time Data
Management
Request/Reply
Security
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
Real-Time Data
Management
Request/Reply
Security
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
Real-Time Data
Management
Request/Reply
Security
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 DDS
library
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 of
Transport 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 Forecasters
and 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 comprehensive
tutorial
– 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: jgilmore@opensystemsmedia.com

Standards for Autonomous and Secure Microgrids

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (12)

Similar to Standards for Autonomous and Secure Microgrids

Similar to Standards for Autonomous and Secure Microgrids (20)

More from Real-Time Innovations (RTI)

More from Real-Time Innovations (RTI) (18)

Recently uploaded

Recently uploaded (20)

Standards for Autonomous and Secure Microgrids