Two IIoT Microgrid Projects With a Common Architecture

By Harry Forbes

Industry Trends

​The Industrial Internet Consortium (IIC) recently announced it will be creating an energy-focused testbed, in partnership with electric utilities CPS Energy (San Antonio, TX) and Southern California Edison. IIC member companies Cisco, National Instruments and Real-Time Innovations (RTI) will also contribute to the testbed.

What's most interesting about this testbed is that it will be extending the work done by Duke Energy and its supplier partners over a number of years – work which has culminated in Duke's publication of a reference architecture for what they call a "Distributed Intelligence Platform" (DIP). This architecture shares quite a bit with the Industrial Internet of Things. Though this IIC testbed (as well as one Duke Energy is building) will be energy-focused, much of the architecture is generally applicable to industrial applications.

Duke Energy has extensive experience with IoT-like distributed systems and applications, stemming from its work with Ambient Corporation (see this ARC report from 2011 on that collaboration). After the 2008 financial crisis, electric utilities were major recipients of government stimulus investments, mainly targeting smart metering and smart grid applications. Duke and Ambient took a different approach to building this type of system. Realizing that they could not scale up their SCADA systems to manage their grid at such a micro level, they created a decentralized architecture and brought intelligence and automation to the edge of the grid. They deployed over 100,000 network-agnostic and protocol-agnostic field "nodes", developed a zero-touch node deployment capability, and added embedded computing to the nodes. They did all this a long time before the term s IoT and Fog Computing became fashionable.

The recent Duke Reference Architecture expands on this history in two important ways; first, it specifies a virtualized Linux environment for applications, and second, uses the Data Distribution Service (DDS) standard to provide a Field Message Bus (FMB, see the figure). The FMB is conceptually similar to an Enterprise Service Bus (ESB), but is much more oriented toward scalable, real-time applications that operate 24/7 and require the ability to self-heal and operate autonomously. DDS was part of the venerable iDA (interface for Distributed Automation) architecture, developed in the early days of Industrial Ethernet (2002). The technology has developed since then, most notably adopting a standard security model. DDS has been used in diverse applications over the intervening years.

Duke FMB.jpg

Duke's Reference Architecture Addresses Both IT and OT
(Source: Duke Energy)

While the IIC testbed is just beginning now, Duke Energy is planning to further develop their existing microgrid testbed and demonstrate its progress at the 2016 DistribuTech event in Orlando (which takes place the same week as ARC’s 2016 Industry Forum in Orlando). Duke wants to demonstrate interoperability by using 2 suppliers for every function in its microgrid test bed. This will include solar PV, energy storage, utility distribution equipment, and consumer devices located “behind the meter”. Duke will also be working with several utility groups (SGIP, NAESB, and UCAlug) to further standardize and promote parts of this architecture.
There are several important take-aways from these 2 programs, in ARC’s opinion:

  • These testbeds are designed to support very operational activities and grid edge automation, which Duke believes is increasingly important as energy consumers add smart energy devices like rooftop solar PV systems, plug-in hybrid vehicles, and energy storage.
  • Using DDS is a wise move as it is existing, well suited, standardized, supported by multiple vendors, and reasonably mature.
  • Duke will be choosing or developing device profiles as part of this work. This has been done already ad nauseum by organizations such as the ZigBee Alliance, so both projects should borrow extensively and avoid re-inventing in this area as much as possible.
  • Duke will need a distributed application deployment, update, and monitoring capability. Partners such as Cisco have deep expertise here. Utilities generally do not.
  • Many utilities (including Duke Energy) are required by regulation to treat smart meters as a line of demarcation with their customers and as an interface to smart devices located on the customer premises. This (in ARC’s opinion) is an unworkable rule going forward for several reasons. A good testbed will offer a way to see how well this really will work.

ARC expects some interesting results to come from these projects, and the participants should be reporting at the same time as the next ARC Industry Forum (in Orlando). Stay tuned.

Engage with ARC Advisory Group