To SCADA or not to SCADA ...
- Jul 23, 2018 2:12 pm GMT
- 1798 views
… that is the question. No, not the one asked by Hamlet but one that utilities are asking as they consider upgrading, replacing or installing a distribution SCADA system typically as part of or related to a SmartGrid or Integrated Grid project. Why the question? Well, things have changed since SCADA was first used to monitor and control substations associated with the transmission grid. At many utilities the distribution grid was somewhat the awkward stepchild who was ignored when it came to automation.
That began to change around the early ‘90s. An example of that change occurred at Southern California Edison (SCE). Two projects at SCE ushered in the era of automation to the distribution grid. The first of those was the implementation one of the first large scale outage management systems (OMS). This provided distribution operations the first graphical view of what was happening on their part of the grid. Because of the integration with the Customer Information System (CIS) for trouble tickets as well as with GIS and asset management applications, the OMS, as is still typical today at most utilities, was implemented on the Information Technology (IT) side of the network rather than on the Operational Technology (OT) network. At that time the chasm between IT and OT was very wide and had not been crossed.
Prior to the OMS implementation there had been forays into distribution SCADA, one based on a separate SCADA system which utilized a PC to provide the RTU functionality and one based on the existing SCADA used for the transmission network. While both provided a standalone view into the distribution grid it was limited with no association to the broader perspective of the grid that OMS provided. This also required operations personnel to view two separate user interfaces on separate computers. To eliminate that problem required the crossing of the OT/IT chasm.
With a little bit of slightly “clunky” technology integration between the SCADA system and OMS was accomplished in a minimal way. Changes in distribution breaker status were communicated from SCADA to OMS creating an alarm in OMS as well as integrating that information into the trouble ticket analysis. A hurdle that had to be overcome was the SCADA circuit breaker point nomenclature versus the OMS circuit nomenclature. OMS treated the substation as a ‘black box’ or as a point from which circuits were shown to emanate. To tie the SCADA point providing the breaker status to the circuit name a ‘table of correspondence’ (TOC) was created and maintained.
The second major project, Netcomm (Network Communications), was a precursor to today’s AMI (Advanced Metering Infrastructure) utilizing intelligent meters and a mesh radio network. Initially focused on the meter reading aspects, as today’s AMI was, it became apparent that the radio network in conjunction with the meters could provide Distribution Automation (DA) capabilities. One initiative, dubbed CARLA (Circuit and Automatic Recloser Alarm), provided alarms to OMS if a radio placed at the head of a circuit or behind an AR went on battery backup implying a loss of power on the grid. Similarly branch line fuses could effectively be monitored. Another initiative was remote switching also accomplished using the radios and integrated with OMS. A third initiative was intelligent, autonomous automation of distribution capacitor controllers to regulate voltage.
While all three initiatives provided a form of SCADA capability none of them were integrated with SCADA. The plan for the capacitor control was to eventually integrate with the substation capacitors, the OT/IT divide technically, as well as in part culturally, prevented that integration. Because the other initiatives integrated directly with OMS, providing the distribution operators a common view of the distribution grid, there was no need to integrate or utilize SCADA relative to the initiatives. In effect, with these initiatives integrated with OMS, SCE had created an early version of what is known now as an Advanced Distribution Management System (ADMS) integrated with SCADA and other technologies to provide data acquisition and control capabilities.
Coming back to today, what has changed? For one thing there are a lot more acronyms floating around: DA is now getting more play; AMI is providing not just meter reading but events (power off/on) and data (e.g. voltage) related to the distribution grid; DER (Distributed Energy Resources) provides data from and requires the ability to control both real and virtual assets with integration within and external to the utility; OpenFMB (Field Message Bus) provides the protocol for devices to communicate and perform autonomous but coordinated operations without needing to make a round trip to a central location. Distribution transformers or sensors attached to them now have the capability to provide real time information about the transformer such as temperature and voltage; intelligent switches and other devices are key components of DA. Solution offerings in these areas employ a variety of standard and proprietary protocols, network communications and typically separate user interfaces.
Another change has been the role of analytics and, relative to this discussion, what is known as asset health analytics. A robust asset health analytics program requires information from grid operations and from other business capabilities such as asset maintenance and inspection. This means that it requires information that is housed in both the OT and the IT houses. While the OT side is still more likely to view the assets, or the Power System Resource (PSR) in IEC CIM terms, from a SCADA point, or multiple points per PSR, perspective, the IT side views the asset from it physical perspective as a uniquely identified entity. This requires a more effective version of the TOC implemented by SCE to ensure all data about an asset, regardless of source, can be correlated and utilized in the analytics.
Coming back to the question of the use of SCADA, while SCADA has evolved over time moving out from the substation and into the field, utilities are now looking at what is sometime referred to as ‘SCADA Like’ or ‘SCADA Lite’ systems. The requirements being addressed by these systems include:
- Integration with a disparate and ever changing collection of field devices utilizing different protocols
- Integration with multiple applications on both the OT and the IT side including OMS, ADMS, DERMS, Asset Management, Asset Health Analytics programs and with concepts such as OpenFMB as well as traditional SCADA systems
- Intelligent collection and processing of data from the field devices
- Securely communicating across the OT/IT divide
- Rationalizing disparate asset identifiers (i.e. a better TOC)
- Rapid integration with new devices, technologies and applications
- Meeting performance requirements while addressing issues such as latency and multiple communication networks with different characteristics
An example of addressing these requirements is provided by an implementation at Kansas City Power & Light (KCP&L). Similar to what SCE accomplished in a minimal way, KCP&L wanted to integrate multiple DA systems that encompassed 30 devices types, 3,200 individual devices and over 90,000 points with their OMS, Oracle’s Network Management System (NMS). By integrating separately managed sources of data and alarms with NMS the number of applications that the Distribution System Operators (DSO) would have to interact with could be reduced from six to two.
KCP&L considered upgrading their existing distribution SCADA system to provide this integration. However, in evaluating that option, it was apparent that a large amount of custom integrations would be required to address the variety of devices, protocols and communication networks involved as well as the data management required to provide a consistent definition of the devices across the systems. Not only would this drive up the cost of the project, but it would also lengthen the implementation time as well as present ongoing maintenance costs to support the integration. As existing devices and DA systems were upgraded and replaced the potential would exist for even further integration costs.
KCP&L found a solution in an architecture known as an Operational Technology Message Bus (OTMB). OTMB is a term coined by LiveData Utilities (www.livedatautilities.com). While conceptually similar to Enterprise Service Bus (ESB) middleware running on the IT network, an OTMB is architected to meet the specific needs of OT including in memory processing, high availability, multiple protocol support, template based data flow configuration, service reliability and ESB integration to exchange data with IT systems. By implementing an OTMB, based on Live Data Utilities’ RTI Server, KCP&L was able to implement integrated data display and device control capabilities into their OMS. A high level view of the architecture is shown in Figure 1.
An example capability was FLISR (Fault Location Isolation Service Restoration) which requires status data from multiple devices and the ability to control the devices to restore service. Proof of the viability of the architecture and the underlying technology was demonstrated shortly after implementation when a major outage occurred. Utilizing the new capabilities, the DSOs were able to see the impact of the outage, which devices were affected and issue commands to devices to restore power in a significantly reduced amount of time.
For KCP&L the answer to the question was ‘not to SCADA’ but to use an architecture and technology that provided SCADA capabilities and more resulting in an integrated system of systems while also future proofing them in the ever changing utility landscape. Further information on their implementation can be found at www.livedatautilities.com/scada_alternative.