Utilities Collaborate on Open-Source Software

Avista-owned vanadium flow battery in Pullman, Washington, U.S.

Commercial rooftop solar/inverter installation in Spokane, Washington, U.S., part of shared energy economy project.

Systems

Many utilities do not have fully featured distribution management systems (DMSs) in operation yet. Distributed energy resources (DERs) often are installed by third parties without emphasis on grid operational needs and distributed generation impacts. Yet, even with knowledge of and data flowing from the DERs, reliable dispatch of the resources is challenging. Distributed energy resource management systems (DERMs) have been developed to provide this dispatch, but they typically do not integrate effectively with the DMS. Outage management systems (OMSs) also should integrate with the DMS and DERM for resiliency needs, data needs and state awareness. Typically, these are separate systems with disparate and proprietary databases and topologies.

Quite frankly, the state of operational technology options provided to the industry are costly, functionally inadequate, difficult to integrate, and inconsistent across vendor offerings. There are many standards, yet no common element. The industry seems caught in a legacy environment that challenges vendors to forgo their current offerings and redesign them, but to what specific standards or architectures?

In the smartphone industry, looking at Apple’s iOS or Google’s Android operating systems, the answer seems obvious. Smartphone owners have endless opportunities for value, with offerings from myriad software developers. The operating system provides foundational services on which rich applications can be developed. Ambiguity as to the foundation disappears and, in fact, can be improved continuously for the benefit of everyone. Recently, several utilities collaborated to achieve a similar outcome for utility operational technologies.

Pathway to Creation

Avista Utilities Inc. and Duke Energy Corp. collaborated financially to create, at the direction of the entire utility industry, an energy operating system called the Open-Source Distributed System Platform (OpenDSP), which intends to provide a fundamental package of services in an energy operating system that supports standards, yet is code and not just another standard. Open source and utility industry-driven, OpenDSP can be distributed, centralized or both (hybrid). It supports grid-edge computing; will be scalable, easy to extend and flexible; and will provide the opportunity to achieve true interoperability and interchangeability. Additionally, OpenDSP should be affordable and deployable for utilities of any size.

This partnership builds on the Duke Energy Emerging Technology Office’s (ETO) pioneering work to explore open grid standards through the creation of the Open Field Message Bus (OpenFMB). The OpenFMB interoperability framework is a standard ratified in 2016 by the North American Energy Standards Board (NAESB). It enables traditional grid-edge operational assets and DERs—such as solar photovoltaics, energy storage systems and microgrids — to communicate quickly and securely with each other in the field regardless of each device’s local communications protocols. This interoperability framework will help the energy grid to operate more efficiently, delivering better performance to customers and grid operators.

Duke Energy DC-coupled solar and storage, interface and metering equipment under test at Mount Holly, North Carolina, U.S.

Organization

Any and every utility globally is welcome to participate in the definition of requirements, architecture and business model that defines the licensing, access, oversight and maintenance of OpenDSP. Creation of OpenDSP requires focused efforts in each of these areas and provides opportunities for those with resources to commit as well as those without to participate meaningfully.

Three working groups have been established to develop the business model, core requirements and architecture critical to delivering the OpenDSP core. Open Energy Solutions Inc. (OES) has been tasked with the initial development. The U.S. Department of Energy’s (DOE’s) national laboratories are assisting with logistics, technical support and research. Discussions are underway with other industry organizations, as well. Two committees have been established to provide guidance as well as a path for collaboration and input into any aspect of OpenDSP for interested parties.

Early Structure

The business model working group is tasked with determining how the OpenDSP, as an open-source product, will be structured for development, maintenance, distribution, governance and member participation. The group is committed to an open-source approach that drives innovative solutions from the vendor community. These questions and many more will be resolved by the group: What open-source licenses should be used? Who can contribute code to the core OpenDSP? How will decisions be made regarding development of the core? What are the funding requirements and who can fund the core development and maintenance? How can an investment in the core be recouped?

Initially, the business model working group is open only to utility industry representatives, with additional participation as appropriate. It is understood a caretaker for OpenDSP must be established, and initial steps have been taken to establish EnergyOS as the open-source foundation for this purpose.

The core of OpenDSP is intended to be skinny, flexible, and capable of supporting and enabling the creation of applications or functional use cases for a multitude of utility, market and customer solutions. Specific use-case solutions should not be included in the core, although the core should support open development of functionality to meet the use-case needs. The core platform functions and requirements working group is tasked with developing the common core functional requirements. An array of use cases will be cataloged to ensure adequate understanding of the necessary core capability.

Early Bundles

Avista and Duke Energy intend to develop a number of applications or bundles of use-case functionality that will demonstrate OpenDSP focused on outage management, distribution management, and DER integration and operations. Simultaneous development of these applications on the OpenDSP core will demonstrate the capability of the platform. These applications may be available as open-source offerings when completed.

Avista crews install a smart streetlight sensor on the Gonzaga University campus. The sensor monitors sound, motion, and numerous environmental parameters. OpenDSP could leverage this data to predict earthquake scenarios, pole impact or failure, or identify poor air quality for citizenry.

Based on a modern architecture, OpenDSP will use micro-services and be capable of hybrid or distributed deployment. The architecture will leverage work funded by the DOE that identifies the laminar coordination framework as a best practice to optimize systems for outcomes at various hierarchical levels within the grid. Fundamental to delivering the core is an understanding of how the core should be architected. What services must be included? What services should be excluded? For example, is topology provided in the core architecture?

The effort of this working group thus far has identified several core services for inclusion. This list informs the initial development but will be reviewed constantly as necessary by the working group. The architecture envisioned frees utilities from proprietary solutions and unlocks opportunity for all industry providers and utilities.

Working Groups

The steering committee initially is intended for membership by any utility. Ultimately, OpenDSP must support safe and reliable operation of the utility grid, which is why initial membership is limited to utilities only. For example, consideration of core requirements, architecture and the business model cannot compromise safety over purely economic objectives. As the core matures, membership opportunities may open for other industry players.

Membership on the stakeholder committee is open to all interested parties. The obligation of this committee is to inform the steering committee, with the intent to get requirements vetted and approved for consideration as core services or core extensions.

Platform Overview

OpenDSP is a micro-service-based architecture built on a specific Linux variant with packaged services. The initial project is anticipated to be five quarters in duration, delivering a completely functional beta version with a reference application, code samples and approximately four functional bundles of code being demonstrated at Avista and Duke Energy. OES will build the initial version of OpenDSP based on input from the working groups as well as the steering and stakeholder committees. Online resources will provide access to OpenDSP.

OpenDSP is intended to be completely open and to not dictate either commercial or open-source products. For example, cloud services are a critical component to internet of things (IoT) platforms. As such, OpenDSP must support available cloud services. There will be additional services OpenDSP must support.

Participation Opportunity

More than a dozen utilities met in New Orleans, Louisiana, U.S., in February 2019, approximately one year after a pre-kickoff meeting was held on the collaborative industry effort. More than 40 utilities have interacted to date.

Additional utility collaborators actively are being sought and working meetings tentatively are planned throughout 2019, with Golden, Colorado, U.S., being the next likely meeting spot. Please contact the authors to obtain additional information concerning the effort or contact OES, the facilitator for OpenDSP activities, at [email protected].

Sidebar: OpenDSP Schedule

The intent is to build the Open-Source Distributed System Platform (OpenDSP) as quickly as possible. Every day that passes brings additional industry transformation without adequate tools to deliver value effectively to utility customers while still maintaining a safe, reliable product with distributed energy resources (DERs).

Four phases are scheduled to deliver capabilities in the form of services and applications:

Phase 1

• Adapter interfaces
• Message processors
• Core reference architecture
• OpenDSP product requirements
• Interface integration
• Graphical visualization

Phase 2

• Distributed historian
• Fault management
• Time-synchronization coordination
• Coarse DER forecast
• DER circuit segment management
• Message visualization
• Human-machine interface

Phase 3

• Device discovery
• User experience services
• Simulators
• Circuit segment optimizer
• Voltage management
• Outage intelligence

Phase 4

• Distributed security services
• Distributed network virtualization
• Solar smoothing
• Island detection

At the end of phase 4, OpenDSP will be considered a fully functional beta release with OpenDSP code, a reference application to evaluate the platform easily and documentation available for download.