Harnessing DDS in Next Generation Smart Energy Systems Webcast. November 5, 2014

Transcription

1 Harnessing DDS in Next Generation Smart Energy Systems Webcast November 5, 2014

2 Webcast Presenters Stuart Laval Manager, Technology Development, Duke Energy Stuart Laval is a member of Duke Energy s Emerging Technology office, where his primary responsibility is on Smart Grid telecom-related activities. He also brings over 10 years experience in product development at manufacturers of utility equipment, cellular radio modules, and power semiconductor devices. Stuart has contributed to the successful launch of over 20 product innovations in mid-voltage smart grid sensors, 2G/3G wireless communication, consumer lighting, and audio amplifiers. Stuart holds Bachelors and Masters degrees in Electrical Engineering and Computer Science from MIT and a MBA from Rollins College. Angelo Corsaro CTO, PrismTech Angelo Corsaro, Ph.D. is Chief Technology Officer (CTO) at PrismTech where he directs the technology strategy, planning, evolution, and evangelism. Angelo leads the strategic standardization at the Object Management Group (OMG), where he co-chairs the Data Distribution Service (DDS) Special Interest Group and serves on the Architecture Board. Angelo is a widely known and cited expert in the field of real-time and distributed systems, middleware, and software patterns, has authored several international standards and enjoys over 10+ years of experience in technology management and design of high performance mission- and business-critical distributed systems. Angelo received a Ph.D. and a M.S. in Computer Science from the Washington University in St. Louis, and a Laurea Magna cum Laude in Computer Engineering from the University of Catania, Italy.

3 DDS Overview Angelo Corsaro, PhD Chief Technology Officer

4 The DDS Standard DDS is an Object Management Group (OMG) Standard for efficient, secure and interoperable, platform- and programming-language independent data sharing DDS standardises: - Programming API - Interoperable wire-protocol - Extensible Type System - Data Modeling - Remote Procedure Call

5 Data Distribution Service (DDS) DDS provides a Global Data Space abstraction that allows applications Data Writer Data Reader to autonomously, anonymously, securely and efficiently share data Data Writer Topic D QoS Data Reader DDS Global Data Space is fully distributed (decentralised), highly efficient and scalable Data Writer Topic A QoS Topic C QoS Topic B QoS... Data Reader Data Writer Data Reader DDS Global Data Space

6 Data Distribution Service (DDS) DataWriters and DataReaders are automatically and dynamically Data Writer Data Reader matched by the DDS Discovery A rich set of QoS allows to control existential, temporal, and spatial properties of data Data Writer Data Writer Topic A QoS Topic C QoS Topic D QoS Topic B QoS... Data Reader Data Reader Data Writer Data Reader DDS Global Data Space

7 Key Highlights Elegant and High Level Data Sharing Abstraction Polyglot and platform independent Java, Scala, C, C++, C#, JavaScript, CoffeeScript etc. Android, Windows, Linux, VxWorks, etc. Peer-to-Peer by nature, Brokered when useful

8 Key Highlights Content and Temporal Filtering (both sender and receiver filtering supported) Queries 20+ QoS to control existential, temporal, and spatial properties of data

9 Domain DDS data lives within a domain A domain is identified with a non negative integer, such as 1, 3, 31 The number 0 identifies the default domain A domain represent an impassable communication plane DDS Domain

10 Partitions Partitions are the mechanism provided by DDS to organise information within a domain Access to partitions is controlled through QoS Policies Partitions are defined as strings: - system:telemetry - system:log - data:row-2:col-3 Partitions addressed by name or regular expressions: - system:telemetry - data:row-2:col-* Partitions

11 Topic A Topic defines a domain-wide information s class Topic D QoS A Topic is defined by means of a (name, type, qos) Topic A QoS tuple, where name: identifies the topic within the domain Topic C QoS Topic B QoS... type: is the programming language type associated with the topic. Types are extensible and evolvable qos: is a collection of policies that express the non-functional properties of this topic, e.g. reliability, persistence, etc. Type Name Topic QoS

12 Topic and Instances As explained in the previous slide a topic defines a class/type of information Topics can be defined as Singleton or can have multiple Instances Topic Instances are identified by means of the topic key A Topic Key is identified by a tuple of attributes -- like in databases Remarks: - A Singleton topic has a single domain-wide instance - A regular Topic can have as many instances as the number of different key values, e.g., if the key is an 8-bit character then the topic can have 256 different instances

13 11/3/2014 Copyright 2014 Duke Energy All rights reserved. page 1 Duke Energy Emerging Technology Office Harnessing DDS in Distributed Intelligence Platform Stuart Laval

14 Customer Premise Distribution Circuit Substation Sherrill s Ford, Rankin, McAlpine Substations 6 McAlpine circuits ~60 homes served by McAlpine circuits 11/3/2014 Copyright 2014 Duke Energy All rights reserved. page 2 Duke Energy Test Areas: Integrated Grid Ecosystems Solar PV Energy Storage Dist. Mgmt System PMU (6) Weather stations (7) Line Sensors (200+) Solar PV CES, HES Energy Storage Comm. Nodes (3,000) Intelligent Switches DERMS/DMS AMI metering (14,000) Solar PV Home Energy Manager PEV Charging Stations Smart Appliances Demand Response In-home load monitoring

15 SUPPLY ELECTRIC GRID DEMAND DIP: Internet of Things Platform for the Utility Smart Assets Smart Meter Transformer Other Nodes Line Sensor Distributed Energy Resources Capacitor Bank Intelligent Switch Street Light X Smart Generation Continuous Emission Monitoring Weather Sensor Open Standards Node 4G LTE, Wi-Fi, GPS Ethernet, Serial PLC, RF ISM, Bluetooth I/O, Metrology, Fiber Processor(s) + Memory Linux-based OS Open API Messaging 3 rd Party Apps Security / Network Mgr IP Network IP Router Capabilities Optional Connectivity Distributed Computing UTILITY DATA CENTER Network Router Legend Required Optional Head End A Head End B Head End N Data Center Message Bus 11/3/2014 Copyright 2014 Duke Energy All rights reserved. page 3

16 Integrated in End Device (as Software) Flexible Hardware & Software Platform Substation Rackmount Server(s) Retrofit Inside Cabinet Pole Mounted Enclosure Padmount Enclosure Copyright 2014 Duke Energy All rights reserved. 4

17 Enabling Distributed Energy Resources with Intelligence at the Edge Current State Centralized Decision-Making Solar PV Future State Distributed Decision-Making Solar PV Meter Transformer Rapid Swing in Production Pass-Thru Sensor Battery Storage Meter Transformer Node Rapid Swing in Production Line Sensor Battery Storage Field Message Bus Response Decision Response Decision + Update Model Line Sensor Head End Cellular Network Utility Office Line Sensor Head End Update Model Cellular Network Utility Office >1 Min < 0.25 sec Copyright 2014 Duke Energy All rights reserved. 5

18 Field Test: Community Energy Storage Shifting & Smoothing Node w/ Field Msg Bus In-rush Smoothing Copyright 2014 Duke Energy All rights reserved.

19 Field Message Bus: The Distributed Internet of Things Enabler CIM DDS Interoperability between OT, IT, & Telecom Modular & Scalable Hardware and Software End-to-End Situational Awareness Distributed Intelligence Platform Copyright 2014 Duke Energy All rights reserved. 7

20 AMI Smart Meters Distributed Architecture: Telecom Networking Vision Multi-level Hierarchy: Seamless, Modular, Scalable End Points Devices Local Area Network (LAN) Lower Tier Nodes (e.g. grid) Router Wide Area Network (WAN) Middle Tier Nodes (e.g. substation) Upper Tier Central Office (Utility Datacenter) Head end Firewall MDM Middleware SCADA DMS Router Middleware Corporate Private Network Tier 5 DIP Node Protection & Control Distributed Energy Resources Local Area Network (LAN) Router Middleware Field Area Network (FAN) Virtual Firewall Legend Core Processor Application Processor Physical Transport Virtual Telemetry 11/3/2014 Copyright 2014 Duke Energy All rights reserved. page 8

21 Publish Subscribe Publish Subscribe Publish Subscribe Publish Subscribe Subscribe Publish Analytics Convergence of OT and IT Use-Case App(s) IT Messaging DDS, MQTT, AMQP, CoAP OPEN API MESSAGE BUS Security Compression Translation Head-End DNP Modbus Other OT OT System or Device DMS Sandbox Pi FCI line Sensor Intelligent Switch Cap Bank Smart Meter Battery/PV Inverters Transformer Telco Router Copyright 2014 Duke Energy All rights reserved.

22 Why Employ a Field Message Bus Architecture with DDS? Pub-Sub Advantages vs. Polling Standard Interfaces & Dictionary Flexibility & Resiliency Unlocks Modularity Scalable Infrastructure Organizational Efficiencies Copyright 2014 Duke Energy All rights reserved. page 10

23 Why is the DIP (w/dds) Important for Duke Energy? 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 2014 Duke Energy All rights reserved. page 11

24 VORTEX in Smart Energy and Utilities Angelo Corsaro, PhD Chief Technology Officer

25 The Vortex Platform Vortex Device Vortex enables seamless, ubiquitous, efficient and timely data sharing across mobile, embedded, desktop, Tools cloud and web applications Vortex is based on the OMG DDS standard MaaS Integration Vortex Cloud

26 Smart Metering with VORTEX

27 Large Scale Smart Metering Tens of millions of Smart Meters for various kinds of utilities, e.g., electricity, water, etc. More and more utilities companies want react in real-time consumption and usage patterns Edge analytics are key for scalability, yet aggregated information is also needed Data should be scoped but not sealed, in order terms, when needed an application should be able to get down to a smart counter data stream, regardless of its deployment

28 Adding Hierarchy Nations are usually organised in Regioni

29 Adding Hierarchy Each Regione, say Tuscany is further organised in Province Notice that in this picture, Firenze does not denote the Town but the Provincia headed by the town of Florence

30 Adding Hierarchy Each Provincia is further organised in Comuni Did you notice Vinci? That s where Leonardo Da Vinci comes from. Da Vinci is the Italian for From Vinci

31 Adding Hierarchy Each Comune is further organised in Quartieri (well things are a bit more complex in reality) We will assume that no further hierarchy will be added beyond that of a Quartiere and that the level just below is that of individual users and thus smart counters

32 smart-counter The Full Picture smart-counter smart-counter smart-counter smart-counter smart-counter

33 Challenges Data Rates - The volume of data involved at a national scale several tens of millions of updates per second push toward an architecture in which data is aggregated throughput the hierarchy - Nonetheless, we want to make it possible when necessary to tap into any unaggregated data stream Analytics - Where are the analytics executed? Does that matter? We d like the flexibility to deploy analytics wherever make sense and let the data flow to them

34 Challenges Locality - Communication should exploit locality so to improve efficiency and reduce latency. Unicast and Multicast - Depending on the deployment we may be able to take advantage of some form of IP multicast, will the platform we able to exploit it?

35 Conceptual Solution Conceptually, it would be nice to have a solution in which the infrastructure, could allow us to concentrate simply on which we want to produce/consume Yet, the infrastructure was smart enough to ensure that data sharing was efficient and scalable

36 System Architecture Italia Toscana Lazio... Sicily Firenze... Siena Catania... Siracusa Empoli Firenxe... Vinci Aci Castello Acireale... Catania Avola Noto... Siracusa Centro Campo Marte... Rifredi Centro... Ognina smart-meter smart-meter smart-meter... smart-meter smart-meter... smart-meter

37 Taking a Slice At the bottom level we have the live data coming from smart meters Higher up in the hierarchy we are Nation-level Analytics Region-level Analytics Italia Toscana interested in aggregated analytics For instance, the major of the city may be interested in average consumption at a Quartiere-level while the President of the region may be interested in analytics aggregated by the Provincia Yet at any point in time, anybody Provincia-level Analytics City-level Analytics Quartiere-level Analytics Firenze Firenxe Centro should be able to get down to any kind of data Real-Time Data smart-meter... smart-meter

38 Designing the Information Model Smart-Meter Analytics enum UtilityKind { ELECTRICITY, GAS, WATER }; struct Meter { string sn; UtilityKind utility; float reading; float error; }; #pragma keylist Meter sn struct Index { string key; float value; }; typedef sequence<index> IndexSequence; struct UtilityAnalytics { string scope; UtilityKind utility; IndexSequence indexes; }; #pragma keylist UtilityAnalytics scope

39 Information Organisation DDS Partitions will be used to scope data and provide a flexible way of aggregating it Meter data will be published in a partition composed by nation:region:province:city:quarter:device- sn - italia:toscana:firenze:vinci:centro:a1b27fdz35 - italia:sicilia:catania:acireale:cappuccini:4cafebabe1 Analytics are produced using data at scope n are injected at scope n-1. As an example, the average consumption for the quartiere cappuccini is produced using meter data from italia:sicilia:catania:acireale:cappuccini:* and published into italia:sicilia:catania:acireale:cappuccini and so on Notice that the use of partitions makes very easy to decide which over which sets of data the analytics have to compute

40 The different deployment of VORTEX Cloud are federated to behave as a single instance. This logical instance optimally matches and routes information over a very large scale exploiting locality Region VORTEX Cloud Provincia Analytics VORTEX Cloud Analytics VORTEX Cloud City VORTEX Cloud VORTEX Cloud Quartiere VORTEX Cloud VORTEX Cloud Analytics Appliance VORTEX Device VORTEX Device Analytics VORTEX Device VORTEX Device low-power radio protocol smart meters

41 smart-u

42 smart-u smart-u is a VORTEX demo that illustrates how to implement a smart metering solution For illustrative purposes, some analytics are computed using ESPER other are hand-coded As you ll see with this demo, while scoping information for scalability you can easily access it at any level In addition analytics can be deployed where it makes the most sense Through the VORTEX platform data can be injected and consumed across any platform, Web, Mobile, Embedded, Enterprise and Cloud!

43 Summary In this presentation we have performed how VORTEX can address the challenges of building large-scale real-time smart metering architectures The combination of Vortex Device and Vortex Cloud made it very easy to create and deploy our Internet-Scale, multi-device applications

44 Further information For further information please contact us directly angelo (on-demand live demo available) Or via social media info.prismtech.com/facebook