Every day, operating the grid efficiently becomes more complicated, and the jobs of engineers and Distribution System Operators (DSOs), more difficult. Today, there is an explosion of Distributed Energy Resources (DERs) such as wind, solar and storage being added to the grid daily. While Neils Bohr famously said, “Prediction is very difficult, especially if it’s about the future,” what is clear is the need for scalable technologies to manage an increasingly complex grid of devices, data and systems of systems from here forward.

In conversations with utility system architects, the discussions repeatedly address how complex the grid is becoming. More sensors, more devices, more DERs, more systems to manage all of the new automation equipment is a common theme. A typical scenario is the following:

1. A DSO is about to purchase a new Outage Management System (OMS)
2. The DSO has limited Distribution Automation (DA) today
3. The DSO is using their Energy Management System (EMS) to manage their limited DA
4. The DSO plans to purchase a Distribution SCADA (D-SCADA) system but is unsure about the cost of a D-SCADA system and the complexity of having two different screens/interfaces for their control room operators (one for D-SCADA and one for their OMS)
5. The DSO will want to integrate an Advanced Distribution Management System (ADMS) in the future
6. The DSO also knows they will need a Distributed Energy Management System (DERMS) in the not too distant future
7. The DSO is interested in integrating new IOT-like fault detection as well as voltage and current sensors that don’t necessarily need to be interfaced with the company’s SCADA system
8. The DSO desires an open architecture so they can mix and match best-in-breed applications and systems
9. The DSO knows that there will be an increasing number of new real-time applications from existing and new solution providers. The company leaders want to ensure they can easily integrate these applications that don’t even exist today

As you can see in this scenario, the DSOs are faced with great uncertainty (and opportunity) managing complexity and a system of systems that is changing much more rapidly than anything utility companies have seen in the last 100 years of operations.

The challenge of supporting legacy equipment simultaneously with state-of-the-art DERs while monitoring disparate applications on both the OT and IT systems has created headaches across the industry. Utility operators have the view of the grid that they want and the data that comes with it, but their systems are not designed to handle this type of dataflow from the current system of systems integrations. SCADA systems are sometimes used to integrate this complicated system of systems. Designed primarily to control devices and acquire simple data sets, SCADA systems are not optimized to manage complex dataflows and do not support plug-and-play integrations of new grid applications.

To overcome these challenges, utilities are using the Operational Technology Message Bus (OTMB) architectural pattern within their OT/IT hybrid architectures. This pattern provides an over-arching organization for connecting all the components in a system of systems. OTMB architectures are built on OT-centric middleware. OTMB systems provide for bi-directional communication between SCADA, ADMS, OMS, DERMs and other OT systems, assets and devices utilizing various protocols (ICCP, DNP3, MODBUS, OPC, REST, etc.), IT and OT analytics applications, SQL and historian databases.

OT middleware solves the integration problem of establishing bi-directional communication and control between multiple DERs and systems using a variety of protocols. This single architectural layer enables utility engineers to unify and manage distributed assets and data regardless of their relation to a system or protocol language. Rather than building a point-to-point solution (either in-house or through a team of consultants) every time a new system needs to be integrated into the OT architecture, an OTMB architecture provides a consistent, efficient framework for integration among all devices and protocols.

OTMB architectures are not just about the data plumbing required to manage dataflows among disparate systems. OTMBs can be extended to execute tasks and workflows. For example, they can help manage the challenge DSOs face in matching namespaces (also known as Measurement Management) across systems such as SCADA and OMS. The namespace metadata requires timely maintenance every time new devices are added to the grid or a device location is changed, often consuming much of an operating technician’s time. This time would be better spent optimizing the operation of the system of systems instead of tediously moving configuration files from machine to machine. A well implemented OTMB software pattern will automatically manage the integration of namespaces and measurement metadata across disparate systems and devices, as well as having robust tools to aid in maintenance and manage naming exceptions.

Managing the Future with an OTMB

The previous scenario explains how an OTMB futureproofs this system evolution.

Phase 1 – OMS/EMS integration

The OTMB creates a bridge between an existing EMS and new OMS. This initial step ensures quick integration time between the OMS and EMS. Utilizing the OTMB’s measurement management features ensures the EMS and OMS namespaces are automatically updated as new devices are added to your more and more automated grid. Perhaps as part of this first phase, you would like to add a new or existing operational historian (time series database) into your system of systems. You can achieve this easily through an OTMB. Additionally, the OTMB may be architected to sit in the cybersecurity DMZ. This creates a well-defined secure protocol data exchange bridge between the critical DA system network and your OMS, which sits closer to the IT network.
 

Figure 1. OTMB creates a bridge between EMS and OMS. Utilizing the OTMB’s measurement management features ensure the EMS and OMS namespaces are automatically updated as new devices are added.
 

Phase 2 - Expanding Distribution Automation

Traditionally, DSO architects would implement a D-SCADA system to manage a fleet of DA devices such as automated switches. This scenario works great when you employ an OTMB as part of your system of systems of architecture. The OTMB offers a standard interface and quick integration. Some DSOs have chosen to take a different path. As shown in Figure 2, Evergy (formerly KCP&L) implemented an OTMB architecture and uses the SCADA-lite capabilities to control 3000 field devices directly from their OMS without using a traditional D-SCADA system.

It should be noted, that many DSOs are taking a hybrid approach (see Figure 3) to managing their fleet of DA devices. They are implementing new or re-purposing existing D-SCADA systems to manage their primary DA assets. They are also bypassing their D-SCADA system to integrate some IOT like devices such as current sensors and fault line indicators. Additional expansion in this phase is increasingly including cloud-based, real-time analytics systems with REST interfaces to manage DERMS functionality such as grid storage scheduling and optimization.
 

Figure 2. OTMB architecture employed to integrate SCADA functionality into an NMS transforming it into an ADMS
 

Phase 3 – The Future

As mentioned earlier, the future is hard to predict, but two trends are clear:

1. Distributed Energy Resources, IOT sensors and increased distribution automation will continue to grow at an exponential rate.
2. Smart start-ups with founders still in high school will develop new devices and OT applications that will be must-haves for DSOs managing a much more automated grid over the next 20 years.

Implementing an OTMB allows DSOs to take an organized evolutionary approach to adopting best-of-breed technologies over the coming years. It also allows DSOs to make smart choices about solutions without being locked into a single vendor. Although the future is uncertain, there is much you can learn from the enterprise software architects from 20 years ago. When faced with integrating an explosion of new HR, accounting, MRP and other enterprise solutions, IT architects have adopted middleware solutions. DSOs and OT architects are starting to embrace the same approach with OTMB (OT centric middleware) architectures to ensure a stable OT-centric integration platform to manage the future.
 

Figure 3. An OTMB architectural pattern allows for integration of all legacy, modern and future devices and systems.