SlideShare a Scribd company logo

Standards for Autonomous and Secure Microgrids

•
•
Real-Time Innovations (RTI)
Real-Time Innovations (RTI)

Standards for Autonomous and Secure Microgrids Originally presented on March 19, 2015. Watch On-Demand: http://ecast.opensystemsmedia.com/530

1 of 43
Download to read offline
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 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 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 DataCenterMessageBus 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 Copyright © 2015 Duke Energy All rights reserved. “Internet of Things” Platform for the Utility
Flexible Hardware & Software Platform 11 Retrofit Inside Cabinet Pole Mounted Enclosure Padmount Enclosure Substation Rackmount Server(s) Integrated in End Device (as Software) Copyright © 2015 Duke Energy All rights reserved.
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 Copyright © 2015 Duke Energy All rights reserved.
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” Copyright © 2015 Duke Energy All rights reserved.
Field Test: Community Energy Storage Shifting & Smoothing In-rush Smoothing Node w/ Field Msg Bus Copyright © 2015 Duke Energy All rights reserved.
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 Copyright © 2015 Duke Energy All rights reserved.
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 Copyright © 2015 Duke Energy All rights reserved.
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 Copyright © 2015 Duke Energy All rights reserved.
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 OS & Transport OS & Transport 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 OS & Transport OS & Transport Non-DDS App DDS Routing Service Adapter Non-DDS Device DDS Routing Service Adapter OS & Transport OS & Transport 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
Integrated Capabilities 3/19/15 29© 2015 RTI Transport-Layer Protocol(s) Reliable Messaging Discovery Type System - Evolvable Real-Time Data Management Request/Reply Real-TimeQualityofService Security Data-Centric Publish-Subscribe 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
Integrated Capabilities 3/19/15 30© 2015 RTI Transport-Layer Protocol(s) Reliable Messaging Discovery Type System - Evolvable Real-Time Data Management Request/Reply Real-TimeQualityofService Security Data-Centric Publish-Subscribe Application or Adapter 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
Integrated Capabilities 3/19/15 31© 2015 RTI Transport-Layer Protocol(s) Reliable Messaging Discovery Type System - Evolvable Real-Time Data Management Request/Reply Real-TimeQualityofService Security Data-Centric Publish-Subscribe Application or Adapter Operating System • DDS automatically discovers and connects matching publishers and subscribers • Little or no configuration is required • Systems are self-forming and self-healing
Integrated Capabilities 3/19/15 32© 2015 RTI Transport-Layer Protocol(s) Reliable Messaging Discovery Type System - Evolvable Real-Time Data Management Request/Reply Real-TimeQualityofService Security Data-Centric Publish-Subscribe Application or Adapter 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
Integrated Capabilities 3/19/15 33© 2015 RTI Transport-Layer Protocol(s) Reliable Messaging Discovery Type System - Evolvable Real-Time Data Management Request/Reply Real-TimeQualityofService Security Data-Centric Publish-Subscribe Application or Adapter 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

More Related Content

Standards for Autonomous and Secure Microgrids

  • 1. Duke Energy Emerging Technology Office Standards for Autonomous and Secure Microgrids Stuart Laval 3/18/2015 page 3Copyright © 2015 Duke Energy All rights reserved.
  • 2. 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
  • 3. 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.
  • 4. 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.
  • 5. 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.
  • 6. 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)
  • 7. 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 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)
  • 8. 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 DataCenterMessageBus 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 Copyright © 2015 Duke Energy All rights reserved. “Internet of Things” Platform for the Utility
  • 9. Flexible Hardware & Software Platform 11 Retrofit Inside Cabinet Pole Mounted Enclosure Padmount Enclosure Substation Rackmount Server(s) Integrated in End Device (as Software) Copyright © 2015 Duke Energy All rights reserved.
  • 10. 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.
  • 11. 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 Copyright © 2015 Duke Energy All rights reserved.
  • 12. 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” Copyright © 2015 Duke Energy All rights reserved.
  • 13. Field Test: Community Energy Storage Shifting & Smoothing In-rush Smoothing Node w/ Field Msg Bus Copyright © 2015 Duke Energy All rights reserved.
  • 14. 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.
  • 15. Benefits of the OpenFMB Framework • Customer Benefits • Cost Savings • Risk Mitigation Copyright © 2015 Duke Energy All rights reserved.
  • 16. 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.
  • 17. 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 Copyright © 2015 Duke Energy All rights reserved.
  • 18. 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 Copyright © 2015 Duke Energy All rights reserved.
  • 19. Thank You! For more information contact: Stuart Laval, Duke Energy Stuart.Laval@duke-energy.com page 21Copyright © 2015 Duke Energy All rights reserved.
  • 20. Your systems. Working as one. DDS: Connectivity Framework for Autonomous and Secure Microgrids David Barnett March 19, 2015
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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 OS & Transport OS & Transport E.g.: DNP3, 61850 Physical Network
  • 25. 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 OS & Transport OS & Transport Non-DDS App DDS Routing Service Adapter Non-DDS Device DDS Routing Service Adapter OS & Transport OS & Transport E.g.: DNP3, 61850
  • 26. 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
  • 27. Integrated Capabilities 3/19/15 29© 2015 RTI Transport-Layer Protocol(s) Reliable Messaging Discovery Type System - Evolvable Real-Time Data Management Request/Reply Real-TimeQualityofService Security Data-Centric Publish-Subscribe 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
  • 28. Integrated Capabilities 3/19/15 30© 2015 RTI Transport-Layer Protocol(s) Reliable Messaging Discovery Type System - Evolvable Real-Time Data Management Request/Reply Real-TimeQualityofService Security Data-Centric Publish-Subscribe Application or Adapter 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
  • 29. Integrated Capabilities 3/19/15 31© 2015 RTI Transport-Layer Protocol(s) Reliable Messaging Discovery Type System - Evolvable Real-Time Data Management Request/Reply Real-TimeQualityofService Security Data-Centric Publish-Subscribe Application or Adapter Operating System • DDS automatically discovers and connects matching publishers and subscribers • Little or no configuration is required • Systems are self-forming and self-healing
  • 30. Integrated Capabilities 3/19/15 32© 2015 RTI Transport-Layer Protocol(s) Reliable Messaging Discovery Type System - Evolvable Real-Time Data Management Request/Reply Real-TimeQualityofService Security Data-Centric Publish-Subscribe Application or Adapter 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
  • 31. Integrated Capabilities 3/19/15 33© 2015 RTI Transport-Layer Protocol(s) Reliable Messaging Discovery Type System - Evolvable Real-Time Data Management Request/Reply Real-TimeQualityofService Security Data-Centric Publish-Subscribe Application or Adapter 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
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. 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
  • 38. Broad Adoption and Support • Used by at least 2,000 projects • ~14 implementations • 9 have demonstrated interoperability 3/19/15 © 2015 RTI 40
  • 39. 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
  • 40. 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
  • 41. 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
  • 42. Audience Q & A Stuart Laval, Manager of Technology Development, Duke Energy David Barnett, Vice President of Products and Markets, RTI
  • 43. Thanks for joining us Event archive available at: http://ecast.opensystemsmedia.com/ E-mail us at: jgilmore@opensystemsmedia.com