Without proper preparation, adding distribution automation (DA) devices to SCADA (Supervisory Control and Data Acquisition) systems can be a utility’s own apocalypse. Let’s look at how utilities can avoid communications glitches to gain situational awareness and visibility into conditions in the field.
First and foremost, before adding DA devices to their SCADA systems, utilities must have a plan that answers these questions:
Answering this question involves understanding the utility’s goal, whether it’s grid visibility, control, coordination, or something else. It is also important to understand what devices are being added to the SCADA network, what capabilities the devices have, and whether future use cases involving these devices are already understood.
How much experience in distribution SCADA networks does the utility have and what are the performance expectations?
Utilities must honestly assess how much experience they have with distribution SCADA networks in general and specifically with the devices they want to connect to the network. Utilities also must have a firm grasp on how often they want to access data from devices through status or event polling.
Plus, utilities need to know whether they will want to utilize unsolicited responses from their devices to implement their use cases. This doesn’t have to be an either/or proposition, but this choice can significantly impact the consumption of available bandwidth.
What are the practices the utility’s field crews use when accessing front panel controls on each type of device controller?
In most cases, the utility has devices deployed that have been on their distribution grid for many years. These devices, like reclosers, voltage regulators, and switched capacitor banks, have been performing their functions autonomously without a communication link to a SCADA system.
When connecting these devices to SCADA, a remote-control aspect is introduced that wasn’t there before. Field crew safety and operational concerns must be addressed and this needs to be an active questioning process to make sure the field crew supervisors understand the possible implications.
Once a plan for adding DA devices to SCADA is in place, follow these 3 tips for a successful implementation:
Review, enhance, and test logic on devices before connecting them to SCADA.
Device logic written in the past should be scrutinized to avoid safety issues. Connecting devices to SCADA gives incredible access to what is going on in the utility’s distribution grid and a new level of control that didn’t exist before. However, the new level of control must be implemented correctly and carefully in order to prevent creating safety risks and confusion for field crew personnel.
For example, one utility, during a logic review, found a single incorrect character in a logic string controlling a specific function of a recloser, which is a specialized switch, similar to a breaker, that is designed to clear temporary faults rather than simply opening and staying open when a fault occurs.
In this case, the logic, which had been written many years earlier, was giving a visible indication that an important function was disabled when, in fact, the function was still operational. The logic review was initiated because this device was being added to the utility’s SCADA system which led to the discovery and correction of this important issue.
Make sure the expectations of all stakeholders are clear on how the newly connected DA devices will function especially regarding any changes created by the new communications link to a SCADA Master. Get input from the field operations team directly.
Field personnel have been trained on how particular functions controlled by front panel pushbuttons on DA equipment, like recloser controllers, work. Procedures on how to operate the front panel controls have been documented and are part of the utility’s training program.
For example, field personnel may expect that a pushbutton labeled “Remote Enabled” causes remotely issued commands received by the device to be ignored if the pushbutton indicates the remote function is de-asserted (turned off), usually indicated by a front panel LED being OFF. However, in some devices that logic must be manually programmed to behave in the way the field crew expects.
For some controller manufacturers, the logic that controls front panel pushbuttons, like the one mentioned above, does not come with factory default logic. Whether this is because the manufacturer of the controller does not want to take on the liability of the logic or there are too many variations that utilities want is irrelevant. The fact remains, in a lot of cases the utility must write the logic that manages some of the functions in the device.
With the large variety of device controllers, interfaces, and levels of custom logic it is critical to make sure the personnel programming the devices fully understand the functional expectations of all the stakeholders before they start dusting off device manuals and writing logic. (Maybe PDFs don’t gather dust, but you get my meaning.)
Ultimately, when remote communications are added, utilities should change training materials and retrain of field personnel. Other stakeholders must ensure everyone understands how the newly connected SCADA devices will behave and any new safety practices required to operate and maintain the system safely.
Note: there are many variations of device controllers and variations of pushbuttons or toggle switches called “Remote Enabled” or “Remote/Local,” etc. It is important to tailor and test any custom logic or controller settings to meet the expectations of all stakeholders.
Agree on what data needs to be available from each newly connected SCADA device and what type of control data needs to be written to the device from the SCADA master station.
This is the simplest of tasks, or so it would seem. Each SCADA-ready device or controller typically contains a list of binary I/O (input/output), analog I/O, counters, and other status points that can be made available to the SCADA master. We can call this the point list.
While some devices have many more points available than others, it is important to know which of these points will be required to implement the utility’s use case(s). This could be a simple grid visibility use case or something more complex like CVR (conservation voltage reduction), FLISR (fault location, isolation, and service restoration), or some other use case.
Understanding what grid conditions exist at each device can also drive what points are needed. For example, a 3-phase LVR (line voltage regulator) will have a point list for each phase because typically each phase has its own independent controller. If the distribution system has a DER (distributed energy resource) installation, say a PV (photovoltaic/solar) site, connected on the feeder with the LVR it will likely be important to include points on the points list that pertain to what mode, forward or reverse, in which the LVR is operating. Other LVRs without adjacent DER sites may not require those points.
Some devices have default point lists and others are completely programmed by the user. Most devices fall in-between this range. Consideration should be made before the point list is created or edited regarding what points are needed and why.
Understanding and documenting the why’s are helpful in making sure the data and control will be appropriate and complete for the use case(s) being implemented without consuming network bandwidth with lots of unnecessary points. Also, when future distribution engineers examine the “point list”, it is very helpful for them to understand the reasoning used by previous engineers. Depending on the device and the SCADA system, it can be a daunting task to add an overlooked point after everything is setup.
By employing these 3 tips and smart planning, utilities dealing with the realities of today’s complex grid can avoid hiccups in the process of adding DA devices to a SCADA network.