Sep 2nd, 2015

Smart Switching - The Changing Nature Automation for Smart Grid

The smart grid offers new automation technologies which will benefit the grid. However, it will place greater pressure on operations. New tools are needed to enable a seamless interface between the operators and the automation. OMS operations and DMS operations are overlapping in their responsibility as they both are managing the same grid. A switch plan manager application which straddles both operations is needed, since both control centers use switch plans.

Network switching is a large part of the routine workload for large and small utilities, consuming the bulk of the daily control center operations. A very large majority of utilities use handwritten forms to write, approve and issue switch plans for work crews. Of the few utilities that use electronic forms, these plans are recorded within a spreadsheet or office document. The scheduled plan is verbally communicated or printed and assigned to work crews. The crew in turn verbally communicates their input and comments by radio to the control center, where it is manually recorded by the operator who annotates the switch form.

Utilities are known to implement switch plans comprising as many as 100 or more switching steps per procedure. Large utilities perform as many as 150 switch procedures per day. Although the process is cumbersome and outdated, it has been obviously manageable, until now.

What is changing is that utilities are adopting a more optimized and dynamic feeder network, or "smart grid". Feeder configurations are no longer static but dynamic. Feeder automation will not reduce the switching problem, it will accelerate it. Smart grid automation and analysis will increase the operator's options, which can increase the operator's workload and pressure, if existing processes don't change. One major impingement is that applications, such as self-healing, automatically generate switch plans; for the first time switch plans are no longer solely created by people.

The problem intensifies during major storm scenarios. The automation applications will erupt, producing unplanned, multiple and simultaneous switch plans. For some utilities, these plans require the operator's attention for pre-execution approval. Some utilities configure the program-generated plans to be implemented fully automatically, without operator approval.

For example, during the February 2014 ice storm in Atlanta, a Georgia utility documented that the new smart grid self-healing technology they had installed on 220 feeders resulted in over five million customer minutes saved during the storm period. The smart grid technology of automatic fault detection and isolation adroitly produced switching plans to isolate the faults. Within seconds, an application generated a switching solution to automatically restore service to the upstream and downstream sections of the unfaulted feeder sections.

In a fault-rich environment, a new workload emerges, consisting of high-speed automatic switch plan generation and comprehension. In these situations, the operator needs new visualization tools to follow the plan's automation progress. The system managing the plan must enforce and self-document a structured lifecycle process to record and audit each active switching plan and each step in a plan. A typical lifecycle process will be to request, create, approve, schedule, final approve, implement and archive switch plans.

As aggressive as the smart grid is at achieving its solution function, such as restoration, and as complex as the plans have become with their deeper understanding of network possibilities, what unanticipated issues do they present to the control center operator, and what tools are needed to manage planned and unplanned switching? This paper describes the real-time operational issues, the necessary features and the operational usage of switching automation. It also addresses the impact these changes have on the field crews.

I. Switch Plans: with or without approval?

There are two primary approaches to the smart grid self-healing automation of Fault Detection Isolation and Restoration (FDIR, aka FLISR)-whether to implement it with or without switching approval. Each approach has its benefits. The former relies on an open loop implementation with the operator inserted in the process to close the loop. This is practical in low network fault scenarios and conforms to the industry's historically cautious approach. The latter, which is a closed loop process wherein the action of the operator is removed from the loop, sounds precarious, but its advantage during high stress scenarios is important to consider. Fortunately, we have case studies to consider.

In February 2014, historic ice storms hit the southeast USA. The 2014 storm was the worst in over 10 years, immobilizing ground and air travel throughout the south and leaving up to 550,000 residents without electricity in Georgia and the Carolinas. Twelve months later, another ice storm struck Atlanta.

Notwithstanding, the storms provided a rare stage for the evaluation of smart grid operations under severe stress scenarios. Two Atlanta-based utilities had implemented FDIR self-healing automation technology on over 500 feeders combined. The storm generated multiple network faults, presenting a unique opportunity not only to give the switching technology an unprecedented trial, but also the opportunity to evaluate its mode of operation.

Both utilities experienced the operation of FDIR in a high stress environment. While operating in full automatic mode, each system detected faults, generated a switching solution and automatically executed the remote switching to isolate the fault, then it restored power to the unfaulted feeder sections upstream and downstream. One utility reported that over a three-day period, the FDIR automation technology had correctly handled multiple faults, saving a reported 5.8 million 'customer outage minutes'. The switching restoration of the unfaulted feeder sections took an average of forty seconds, avoiding (in extreme cases) what would have been a fourteen (14) hour outage for some customers.

Furthermore, restoration was successful in spite of heavy loading on backup feeders. The operators observed that automatic load transfer was correctly analyzed to predict a possible overload if a simple load transfer was implemented. FDIR responded by producing switch plans that segmented loads into multiple restoration groups, or to create capacity on the backup feeders by transferring load to a third feeder. The switch plans then safely transferred unfaulted customer loads from the faulted feeder to its backup. In all cases, the FDIR algorithms continued to safely enforce device tags and to successfully manage communication errors while it accomplished the restoration. One utility implemented radio communications, while the other implemented cellular communications to the switching devices.

As the storm progressed, and while the affected feeders were in an abnormal yet restored state, FDIR continued to respond to a second and third fault, dynamically adapting to the abnormal network configuration as it safely implemented full and partial solutions.

Crews worked throughout the storm and afterward to repair the network failures and to remove the network faults. When the crews cleared a feeder's faults, the control center operator, using his cursor to select the feeder, invoked a 'Restore to Normal' command. The automation technology responded by analyzing the network configuration of all affected feeders and automatically generated a switching solution against the abnormal feeder configurations, in order to return their configurations back to normal and to restore the isolated sections. The load flow analysis of the solution guaranteed that the switching sequence was without danger of subsequent overloads, and would avoid momentary outages during any load transfers.

It was reported by both utilities that FDIR did not produce a single miss-operation. The validation of FDIR during the storm has led one utility to undergo a system wide expansion, adding 200 feeders a year under full self-healing automation, while the other utility has achieved l 00% of their feeders under automation. In both utilities, the switching solutions were performed in 'monitor mode', without operator approval of the generation and implementation of the switching plans. The system supports two important monitor mode features that make closed loop switching automation possible:

Advanced monitoring and situational awareness visualization
Advanced switch plan management of the process

A. The Smart Grid Definition of "Automatic"

Fault Detection Isolation and Restoration automation, whether in monitor mode (which is fully automatic) or advisory mode (which is open loop), is implemented in four phases:

Fault isolation
Upstream restoration
Downstream restoration
Return to normal

All utilities are amenable to implementing the first two phases of the FDIR solution in automatic mode, without operator intervention - that is, fault isolation, followed by the upstream restoration since this is routinely performed using commonly deployed peer-to-peer automation schemes.

However, typical peer-to-peer protection schemes normally do not perform restoration through implementation of a downstream load transfer, unless it can be assumed that the circuit is in a standard configuration and that the backup feeder can carry both feeders' loads. Neither of these assumptions are valid during dynamic operations during a storm.

Smart grid self-healing technologies require no such constraint. The smart grid, by definition, is a more dynamic grid, where various applications are able to produce switching solutions to meet different network objectives. A smart grid application can redefine the 'normal' state; therefore any assumption that the circuit has a set 'standard' configuration is too restrictive. In a dynamic smart grid, the control center will implement and manage more switching solutions, many of which were unprompted.

The question each control center must answer is this: will your utility allow the automation application, such as FDIR, to perform the automatic load transfer, without operator approval? In the aviation industry, this mode of operation is called "autopilot".

Utilities are certainly not used to, and accordingly are hesitant, to allow an application to perform switching without operator approval of the switch plan. But some utilities, such as the two Georgia utilities that both operated FDIR during the February 2014 storm, implemented their solutions fully automatic, without operator intervention. The operators from both utilities monitored the telemetered results with their network diagrams, through which the change in network topology displayed the result of the automation as it progressed.

Regardless of which policy is followed-switching with or without approval of the switch plans there are problems that each approach must address within emerging smart grid control centers.

B. Policy can Reduce Switching Success

On a 'blue sky' day, a fault condition will arise and a plan will be generated. If the plan does not require approval (i.e., when the automation is set to 'automatic' mode), the plan is implemented within seconds. If the plan requires approval (i.e., when automation is set to 'advisory' mode), the plan is approved and similarly implemented within minutes. This is how most people visualize the operation of smart grid automation, in a comfortable event-by-event sequence.

However, when the technology is needed most, the event pace will not be leisurely. In an inevitable storm or analogous severe condition, a fault-rich environment will exist. In that situation, multiple plans will be generated within a short time period. The succession of events can rapidly exceed the operator's ability to comprehend the situation.

If the switching solution is set to 'advisory' mode, the utility is required to approve the third and fourth phases of the self-healing downstream restoration. Consequently, the manual analysis of each plan and its subsequent approval will delay the solution. The problem is that all switch plans are perishable. The switch plans were valid under the network topology that existed at the time of the event. The longer it takes an operator or dispatcher to approve a plan, the wider the window in which the switch plan is no longer valid. If a plan becomes invalid and must be regenerated, analyzed and approved, it can significantly add to the operator's workload and stress level.

Wherever an approval process is required in a control center, it is essential that a switch plan manager application efficiently organize all plans and present the plans to the operator with the relevant information needed for analysis and approval. The switch plan application should provide an overview of all active plans and the user interface must enable the operator, using a single click, to quickly locate the plan and to view its extent on the network map. The switch plan manager application must provide the tools to enable the operator to review the plan's actions, to oversee the plans effect, to solicit validation of the plan, to alert of potential clashes with other plans and, if operating under "advisory mode", to enable the approval of the plan for remote control implementation.

C. Switch Plan Validation

Validation is one of the most important features of a modern switch plan application. There are many reasons that the execution of a switching plan may be delayed; whether it is because of planned switching, whether the switching is being manually performed resulting in a delay in implementation, or in the event the system is configured for advisory mode and the operator is busy. Due to the time skew between the plan's creation and the actual switching execution, it is critical that the operator has available a tool within the switch plan manager to 'Validate' the plan in whole or in part. The validation function must check and compare the plan against the current network topology to ensure that network has not changed and that the switching is still valid as planned. The switch plan manager's validation must:

Check for clearance tags that may have been placed on a switching device since the plan was created.
Check for potential overload conditions. At the time the plan was created, there were no violations; however, due to the approval delay or from subsequent switching, the load transfer capacity of the backup feeder may have been dangerously reduced.
Provide a comprehensive analysis which advises of the worst case loading on affected feeders that will be caused by the plan's switching actions.
Check for a feeder loop or parallel and alert the operator of the condition. Some systems, such as Outage Management Systems, do not react favorably to loop conditions.
Check for customer outages resulting from the switching and alert the operator of the expected outage condition.
Check for feeder operational violations, such as high/low voltage, phase imbalance, etc., and alert the operator of the condition.
Check for incomplete single-phase switching and alert the operator of the inconsistent condition.
Check for clashes with other active plans which are switching devices on the same feeders.

The ability of the operator to request a validation of a single plan step, a set of steps, or of the whole plan is critical in order for the operator to gain confidence that the network conditions can continue to support the planned switching procedure. The validation must query the operator to specify a date and time that he expects the switching to take place. It is likely that the planned switching was generated under different conditions on a different day or time of day. The validation must forecast the expected loads for the actual date and time specified and to perform the analysis at the planned time that the step(s) are to be implemented.

D. 'Automatic' Mode Improves Success

Most people instinctively assume that 'automatic' mode is risky, whereas 'manual' or 'advisory' mode switching is less risky. Presumably, 'manual' mode gives the user time to consider the situation with care, whereas 'automatic' mode does not. This assumption may not be accurate.

Ironically, the need to validate a switching plan is reduced while in automatic mode. Since the validation process is used to check for changes in the network, the faster the plan is implemented, the less likely it is that changes have occurred that could invalidate the planned switching sequence. Conversely, the more time it takes to implement the switching sequence, the more critical it is that operators are provided a validation tool to confirm any plan's success. The safest scenario is if the switch plan is implemented automatically, quickly, at the time of the fault.

The utilities involved in the Atlanta storms experienced a solution within twenty to forty seconds, including communication delays, after which the network switching was completed, loads were transferred, restored and the self-healing application was armed for the next event. If a subsequent event occurs sixty seconds later, for example, the application would quickly make the necessary switching changes to the network, adapt to the new network reconfiguration, and re-arm itself for a third event. Both Georgia utilities reported FDIR had executed multiple solutions without an error or violation in the restoration switching plans. This experience endorsed their confidence in their choice to implement FDIR in 'automatic' mode.

Clearly, smart grid automation and advanced analysis capability enhances the operator's ability to generate complex switching solutions. After all, this is the objective of the smart grid. Its solutions, such as optimal switching, operate the network closer to the operating edge and further away from the classical 'standard' configuration. Perhaps 'standard' is now more dynamic, better defined by load and seasonal patterns.

When functioning under 'manual' mode, the operator requires improved analysis tools to account for network changes while implementing more complex plans. However, when functioning under 'automatic' mode, the operator benefits from better visualization tools, which enable him to monitor and review the progress of the automatic switching, much like a pilot monitoring an airplane's instrumentation when following the actions of the auto-pilot.

II. ADVANCED SWITCHING: VISUALIZATION

Prior to the smart grid, switch plans were manually created, manually implemented and easily managed using paper maps. However, smart grid automation will produce switching solutions from unplanned sources,such as an emergency load transfer application or a self-healing application. Other smart grid applications will likewise generate independent switch plans to meet operator requests, such as switching tools to isolate a failed device. Whether in 'automatic' or 'manual' mode, a dynamic summary is required for all of the scheduled plans that the control center is managing, regardless of the source of the generated plan.

Since time is of the essence when reviewing active switch plans, it is important to be able to visualize the plans in relation to the operating map and to visualize the results. As a result of their automation experience with FDIR, one utility (in the Atlanta area) has declared that, by using its visual tools, it has changed the way that they operate within the control center.

A. Visualize Switching Extent

The operator should be able to display all of the active plans in an active plan summary list and visualize them on the dynamic network map. Where multiple plans exist in close proximity, the same device may be operated in more than one plan. The operator should be able to filter and view all currently scheduled plans in order to visually compare each plan relative to the other plans for safety reasons. The switch plan manager should contain a 'clash check' tool within the application, which lists the potential clashes by device between scheduled plans, and alerts the operator of this possibility.

In addition to visualizing active plans on the map, the switching steps of a plan should be visible on the map on a per-plan basis. If the scope of the plan is not easily comprehended, the operator will always be apprehensive about the automation application and wonder "what is it doing"? These features are particularly important during high activity conditions, when the operator is under pressure due to multiple events occurring in continuous succession.

If these tools are lacking when the operator is required to approve all plans prior to their execution,it will hamper the operator's ability to quickly comprehend the plan. This unnecessary delay in plan comprehension will lead to lengthy approval times which could invalidate the switch plan, due to its perishable nature. The faster the operator is able to understand the consequences of the automation and to feel comfortable with the proposed solution, the less likely it is that the plan will have to be replaced with an alternative plan, while under dynamic network conditions. In other words, lack of powerful visualization,comprehension and analysis tools will increase the control center work load, resulting in greater confusion, frustration and work place pressure. The success of feeder automation depends on an informed operator.

B. Switching Map

At one utility in Atlanta, the operators followed the impact of the storm on the network operation using a large high resolution video wall display. It displayed the dynamic network diagram on map, which had hundreds of thousands of dynamic elements. The operators could follow the DMS operation as it highlighted the isolated line sections and dynamically colorized the map to represent the new feeder configurations.What was interesting was that their map of choice was not a geographic map.

Operators regularly operate and perform switching from a detailed geographic feeder diagram, typically a product of the outage management system. However, if operators were given a choice, this would not be their preferred visualization map. The preferred operational map configuration would more likely be a geo-schematic view, which hides the visual clutter of the lines and branches that are not involved in the direct line of switching. Further reducing the diagram's complexity by creating a orthogonal view of the network's trunk lines improves its usability and greatly increases the operator's situational awareness.

Geographic and schematic maps, or a blend of these map configuration options, are needed. However, due to the complexity of building these highly detailed and complex maps, the geo-schematic view variations must be automatically generated from the primary geographic map.

In order to enhance the operator's comprehension of the network at a glance, smart grid visualization must support the integration of the dynamic map options as described-as a canvas, overlaid with the switching details that are in progress.

C. Visualize Plan Progress

As approved plans or automatic plans are executed, the ability to graphically visualize the progress of the switching plan is important for monitoring its execution while in progress.

The operator should be able to control remote devices or update manual switching changes from either the tabular list of the switch plan manager, or from the graphical user interface map display. Operators will refer to the plan's tabular details for a status check on its process, but they prefer to manually execute the step, or the device, from the map diagram for safety reasons. The focus of the execution should be the operator's choice. In addition, as a field crew is assigned to a switching step, the switch plan application should be linked to the mobile crew to download the order to the mobile devices of the assigned crew. Crew input, such as entering the time of manually-executed devices or declaring the step's completion, is uploaded and displayed in the control center on both the tabular and the switching map icons.

If a plan encounters communication errors and cannot be completed, thereby prematurely terminating the plan, the plan's status should reflect this incomplete condition. The switching progress should be visible on the map by color or icon change. The progress should alert the operator to the following conditions:

Alert that a manual plan's step is not assigned/instructed to a field crew
Warn that the switching steps are being executed out-of-sequence
Identify completed steps
Show the next step to complete in the sequence

Operators should be able to formally complete a finished plan and to close the plan upon approval from not only the manager, but from the graphical summary (in cases of high event conditions). Without a tool such as this, the increased activity on the network will spill into the control center, causing unnecessary confusion.

III. SMART GRID SWITCHING: IMPLEMENTATION LIFE CYCLE

A smart grid manager application should record the process and life cycle of all planned switching, as follows:

Request the plan: record time, data and recipient.
First approval:record time, data and recipient.
Schedule for which the plan will be implemented.
Second approval: record time, data and approver (at this point, it is ready to be implemented on the scheduled day).
Assignment of the plan to an operator/dispatcher for ownership of its execution.

The plan should include a cover sheet that outlines the plans details, including electrical information, load information, affected customer information, and the conditions before, during and after the procedure.

IV. SWITCH PLAN MANAGER: MANUAL CREATION INTELLIGENCE

The switch plan manager should possess the same intelligence that the smart grid applications used to automatically create switch plans. These advanced network analysis tools should aid the operator or engineer in the manual creation of switch plans. Switch plan intelligence should be driven from the current state of the real-time network topology, analyzed by the three-phase unbalanced load flow. Building a manual plan, the user should be able to define the date/time of execution in order to determine the approximate load conditions at that time.

The operator creating a switch plan should have access to basic functions evoked from the network map, such as:

Isolate (line or device)
Isolate considering manual switches
Restore
Return to Normal
Load transfer

Evoking these functions should produce a switch plan which is ready for the control center to approve, in accordance with their typical switching life cycle process.

A. Constraint Relaxation

In creating a plan, an impasse arises when a full solution is not available based on network limitations. In such cases, compromises are necessary-by either relaxing the constraints that are preventing a full solution or by accepting a partial plan.

Constraint relaxation should be a parameter which the switch plan displays in percent of the total violation limit of all objects, lines, switches, transformer, etc., associated with the affected feeders in the analysis. The operator should be able to relax or override the normal limit (say 85%) to a higher limit (say 100%) in order to calculate a successful switch plan solution.

Partial plan creation should be guided by an operator-entered preference. The operator should also be able to impose an objective function, such as a maximum load transfer or maximum number of affected customer loads, when determining the switching solution.

B. Macros and Templates

Most lengthy switch plans contain groups of three or four repeatable steps, called macros. In creating manual switch plans, the user should be able to construct the plan using pre-defined macros which will automatically insert the device ID based on the user's selection of the device from the map. Similarly, the system should support Templates, which are predefined steps that are lengthier and more complex than macros.