CONTROL COMMAND DISAGGREGATION AND DISTRIBUTION WITHIN A UTILITY GRID
In one embodiment, a grid controller device of a given locality within a utility grid receive a grid control command and determines a plurality of sub-localities controlled by the grid controller device and one or more grid characteristics of each of the plurality of sub-localities. The grid controller device then disaggregates the grid control command into a plurality of sub-locality control commands according to the grid characteristics of the corresponding plurality of sub-localities, and distributes the sub-locality control commands to sub-grid controllers.
Latest Cisco Technology, Inc. Patents:
The present application claims priority to U.S. Provisional Application No. 61/491,377, filed May 31, 2011, entitled VARIABLE TOPOLOGY DISTRIBUTED INTELLIGENCE FOR SMART GRIDS, by Jeffrey D. Taft, the contents of which are hereby incorporated by reference.
TECHNICAL FIELDThe present disclosure relates generally to utility control systems, e.g., to “smart grid” technologies.
BACKGROUNDUtility control systems and data processing systems have largely been centralized in nature. Energy Management Systems (EMSs), Distribution Management Systems (DMSs), and Supervisory Control and Data Acquisition (SCADA) systems reside in control or operations centers and rely upon what have generally been low complexity communications to field devices and systems. There are a few distributed control is systems for utility applications, including a wireless mesh system for performing fault isolation using peer-to-peer communications among devices on feeder circuits outside of the substations. In addition, certain protection schemes involve substation-to-substation communication and local processing. In general however, centralized systems are the primary control architecture for electric grids.
Moreover, grid control operations generally aggregate control commands at a central point in the utility grid, such as a control center, which is inefficient and does not promote scalability.
The embodiments herein may be better understood by referring to the following description in conjunction with the accompanying drawings in which like reference numerals indicate identically or functionally similar elements, of which:
According to one or more embodiments of the disclosure, a grid controller device of a given locality within a utility grid receive a grid control command and determines a plurality of sub-localities controlled by the grid controller device and one or more grid characteristics of each of the plurality of sub-localities. The grid controller device then disaggregates the grid control command into a plurality of sub-locality control commands according to the grid characteristics of the corresponding plurality of sub-localities, and distributes the sub-locality control commands to sub-grid controllers.
DESCRIPTIONElectric power is generally transmitted from generation plants to end users (industries, corporations, homeowners, etc.) via a transmission and distribution grid is consisting of a network of interconnected power stations, transmission circuits, distribution circuits, and substations. Once at the end users, electricity can be used to power any number of devices. Generally, various capabilities are needed to operate power grids at the transmission and distribution levels, such as protection, control (flow control, regulation, stabilization, synchronization), usage metering, asset monitoring and optimization, system performance and management, etc.
Note that the illustrative structure of the utility grid is shown as a highly simplified hierarchy, e.g., a hierarchy with generation at the top, transmission substations as the next tier, distribution substation as the next, etc. However, those skilled in the art will appreciate that
In the case of distributed control, that is, in terms of control-based hierarchy, substations may be grouped so that some are logically higher level than others. In this manner, the need to put fully duplicated capabilities into each substation may be avoided by allocating capabilities so as to impose a logical control hierarchy onto an otherwise flat architecture, such as according to the techniques described herein. In such cases, transmission substations may be grouped and layered, while primary distribution substations may be separately grouped and layered, but notably it is not necessary (or even possible) that distribution substations be logically grouped under transmission substations.
In general, utility companies can benefit from having accurate distribution feeder (medium voltage/low voltage or “MV/LV” circuit) connectivity information in their software applications and data stores. This is especially useful for outage management and for convenient application to planning, construction, operations, and maintenance. It is, however, very challenging to try to construct or approximate the circuit model within a geographic information systems (GIS) environment due to the complexity of modeling the dynamic nature of an electrical network. That is, while the utility may have an “as-built” database, it may differ from the actual grid for various reasons, including inaccurate or incomplete data capture on grid construction, changes to circuits that are not reflected in updates to the database, and structural damage to the grid. In addition, circuit topology may change dynamically as feeder switches are operated in the course of either normal or emergency operations. Such changes result in an “as-operated” topology that is dynamic and is not reflected in the “as-built” database.
To assist in control of the utility grid, various measurement and control devices may be used at different locations within the grid 100. Such devices may comprise various energy-directing devices, such as reclosers, power switches, circuit breakers, etc. In addition, other types of devices, such as sensors (voltage sensors, current sensors, temperature sensors, etc.) or computational devices, may also be used. Electric utilities use alternating-current (AC) power systems extensively in generation, transmission, and distribution. Most of the systems and devices at the high and medium voltage levels operate on three-phase power, where voltages and currents are grouped in threes, with the waveforms staggered evenly. The basic mathematical object that describes an AC power system waveform (current of voltage) is the “phasor” (phase angle vector). Computational devices known as Phasor Measurement Units (PMUs) have thus been commercialized by several companies to calculate phasors from power waveforms. Because phase angle is a relative quantity, it is necessary when combining phasors taken from different parts of a power grid to align the phase angle elements to a common phase reference; this has been typically done in PMUs through the use of GPS timing signals. Such phasors are known as synchrophasors.
Illustratively, a control center 210 (and backup control center 210a) may comprise various control system processes 215 and databases 217 interconnected via a network is switch 219 to a system control network 205. Additionally, one or more substations 220 may be connected to the control network 205 via switches 229, and may support various services/process, such as a distributed data service 222, grid state service (e.g., “parstate”, a determination of part of the whole grid state) 223, control applications 225, etc. The substations 220 may also have a GPS clock 221 to provide timing, which may be distributed to the FARs 250 (below) using IEEE Std. 1588. Note that a monitoring center 230 may also be in communication with the network 205 via a switch 239, and may comprise various analytics systems 235 and databases 237. The substations 220 may communicate with various other substations (e.g., from transmission substations to distribution substations, as mentioned above) through various methods of communication. For instance, a hierarchy of wireless LAN controllers (WLCs) 240 and field area routers (FARs) 250 may provide for specific locality-based communication between various portions of the underlying utility grid 100 in
Specific details of the operation of the smart grid devices are described below. Note that while there is a general correlation between the communication network 200 and underlying utility grid 100 (e.g., control centers, substations, end-points, etc.), such a correlation may only be generally assumed, and is not a necessity. For instance, FARs 250 may be associated with feeder circuits 140, or may be more granular such as, e.g., “pole-top” routers. In other words, the hierarchies shown in
The network interface(s) 310 contain the mechanical, electrical, and signaling circuitry for communicating data over links coupled to the network 200. The network interfaces may be configured to transmit and/or receive data using a variety of different communication protocols. Note, further, that the nodes may have two different types of network connections 310, e.g., wireless and wired/physical connections, and that the view herein is merely for illustration. Also, while the network interface 310 is shown separately from power supply 360, for PLC the network interface 310 may communicate through the power supply 360, or may be an integral component of the power supply. In some specific configurations the PLC signal may be coupled to the power line feeding into the power supply.
The memory 340 of the generic device 300 comprises a plurality of storage locations that are addressable by the processor 320 and the network interfaces 310 for storing software programs and data structures associated with the embodiments described herein. Note that certain devices may have limited memory or no memory (e.g., no memory for storage other than for programs/processes operating on the device and associated caches). The processor 320 may comprise necessary elements or logic adapted to execute the software programs and manipulate the data structures 345. An operating system 342, portions of which are typically resident in memory 340 and executed by the processor, functionally organizes the device by, inter alia, invoking operations in support of software processes and/or services executing on the device. These software processes and/or services may comprise one or more grid-specific application processes 348, as described herein. Note that while the grid-specific application process 348 is shown in centralized memory 340, alternative embodiments provide for the process to be specifically operated within the network elements or is network-integrated computing elements 310.
It will be apparent to those skilled in the art that other processor and memory types, including various computer-readable media, may be used to store and execute program instructions pertaining to the techniques described herein. Also, while the description illustrates various processes, it is expressly contemplated that various processes may be embodied as modules configured to operate in accordance with the techniques herein (e.g., according to the functionality of a similar process). Further, while the processes have been shown separately, those skilled in the art will appreciate that processes may be routines or modules within other processes.
As noted above, utility control systems and data processing systems have largely been centralized in nature. Energy Management Systems (EMS's), Distribution Management Systems (DMS's), and Supervisory Control and Data Acquisition (SCADA) systems reside in control or operations centers and rely upon what have generally been low complexity communications to field devices and systems. Both utilities and makers of various grid control systems have recognized the value of distributed intelligence, especially at the distribution level.
Generally, distributed intelligence is defined as the embedding of digital processing and communications ability in a physically dispersed, multi-element environment (specifically the power grid infrastructure, but also physical networks in general). In the area of sensing, measurement and data acquisition, key issues are:
-
- Sensing and measurement—determination of quantities to be sensed, type and location of sensors, and resulting signal characteristics;
- Data acquisition—collection of sensor data, sensor data transport;
- System state and observability—key concepts that can be used to guide the design of sensor systems for physical systems with topological structure and system dynamics; and
- Sensor network architecture—elements, structure, and external properties of sensor networks.
Key elements of distributed intelligence comprise: - Distributed data collection and persistence—measurement of electrical grid state, power quality, asset stress and utilization factors, environmental data, real-time grid topology, and device operating states, as opposed to central SCADA;
- Distributed data transformation and analytics—processing of measured data and event messages generated by smart grid devices and systems to extract useful information, prepare data for use by applications, or to correlate and filter data and events for aggregation purposes, as opposed to data center processing; and
- Distributed control—execution of actual control algorithms, with control commands being sent directly to grid control actuators for relatively local controllers, as opposed to central control.
By establishing the network as a platform (NaaP) to support distributed applications, and understanding the key issues around sensing and measurement for dynamic physical network systems, key capabilities of smart communication networks may be defined (e.g., as described below) that support current and future grid applications. In particular, as ICT (Information Communication Technology) networks converge with physical power grids and as “smart” functions penetrate the grid, centralized architectures for measurement and control become increasingly inadequate. Distribution of intelligence beyond the control center to locations in the power grid provides the opportunity to improve performance and increase robustness of the data management and control systems by addressing the need for low latency data paths and supporting various features, such as data aggregation and control federation and disaggregation.
In particular, there are a number of compelling arguments for using distributed intelligence in smart power grids, and in large scale systems in general, such as:
-
- Low Latency Response—A distributed intelligence architecture can provide the ability to process data and provide it to the end device without a round trip back to a control center;
- Low Sample Time Skew—Multiple data collection agents can easily minimize first-to-last sample time skew for better system state snapshots;
- Scalability—No single choke point for data acquisition or processing; analytics at the lower levels of a hierarchical distributed system can be processed and passed on to higher levels in the hierarchy. Such an arrangement can keep the data volumes at each level roughly constant by transforming large volumes of low level data into smaller volumes of data containing the relevant information. This also helps with managing the bursty asynchronous event message data that smart grids can generate (example: last gasp messages from meters during a feeder momentary outage or sag). The scalability issue is not simply one of communication bottlenecking however—it is also (and perhaps more importantly) an issue of data persistence management, and a matter of processing capacity. Systems that use a central SCADA for data collection become both memory-bound and CPU-bound in a full scale smart grid environment, as do other data collection engines; and
- Robustness—Local autonomous operation, continued operation in the presence of fragmentation of the network, graceful system performance and functional degradation in the face of failures, etc.
Standard approaches to distributed processing suffer from shortcomings relative to the electric grid environment. These shortcomings include inability to handle incremental rollout, variable distribution of intelligence, and applications not designed for a distributed (or scalable) environment. Further, existing approaches do not reflect the structure inherent in power grids and do not provide integration across the entire set of places in the grid where intelligence is located, or across heterogeneous computing platforms. Current systems also suffer from inability to work with legacy software, thus requiring massive software development efforts at the application level to make applications fit the platform, and also lack zero-touch deployment capability and requisite security measures.
For instance, one major obstacle in the adoption of distributed intelligence, now is that IP communications and embedded processing capabilities are becoming available in forms that utilities can use, is that utilities cannot make large equipment and system changes in large discrete steps. Rather they must go through transitions that can take years to complete. This is due to the nature of their mission and the financial realities utilities must deal with. In practice, utilities must be able to transition from centralized to distributed intelligence, and must be able to operate in a complicated hybrid mode for long periods of time, perhaps permanently. This means that the utility must be able to roll out distributed intelligence incrementally while maintain full operations over the entire service area, and must be able to modify the distributed architecture appropriately over time and geography. Simply having a distributed architecture implementation is not sufficient; it must be easily and continually mutable in terms of what functionality is distributed to which processing locations in the grid and must be capable of coexisting with legacy control systems where they remain in place. Therefore, there exist various kinds of variable topology for effective distributed intelligence:
-
- Transition Variability—Rollout of distributed intelligence functions will be uneven both geographically (topologically) and over time, and there is no one-size-fits-all solution, even for a single utility;
- End State Variability—Not every distributed intelligence function will be pushed to every end node of the same class, and distributed intelligence functions and distributions will have to change over the life of the system;
- Operational Variability—Users must be able to change locations of functions to deal with failures and maintenance, etc.
Additionally, design and implementation of smart grids at scale poses a number of challenging architecture issues. Many of these issues are not apparent or do not show significant effects at pilot scale, but can become crucial at full scale. Note that generally herein, “at full scale” means one or more of:
-
- Endpoint scale—the number of intelligent endpoints is in the millions per distribution grid;
- Functional complexity scale—the number and type of functions or applications that exhibit hidden layer coupling through the grid is three or more; or the number of control systems (excluding protection relays) acting on the same feeder section or transmission line is three or more; and
- Geospatial complexity—the geographical/geospatial complexity of the smart grid infrastructure passes beyond a handful of substation service areas or a simple metro area deployment to large area deployments, perhaps with interpenetrated service areas for different utilities, or infrastructure that cuts across or is shared across multiple utilities and related organizations.
In the table 400 shown in
The smart grid has certain key attributes that lead to the concept of core function is classes supported by the smart grid. These key attributes include:
-
- A geographically distributed analog infrastructure;
- A digital superstructure consisting of digital processing layered on top of the analog superstructure, along with ubiquitous IP-based digital connectivity; and
- Embedded processors and more general smart devices connected to the edges of the smart grid digital superstructure and the analog infrastructure; these include both measurement (sensor) and control (actuator) devices.
Given this environment, and given our present understanding of the nature of the desired behavior of the power grid, we may identify a number of key function classes; functional groups that arise inherently from the combination of desired smart grid behavior, grid structure, and the nature of the digital superstructure applied to the grid. An understanding of these core function groups is key to developing a view toward a layered network services architecture for smart grids. A model is presented herein in which smart grid applications of any type are built upon a logical platform of core function classes that arise from the grid itself.
Specifically, as shown in the model of
1) The base tier 510 is:
-
- Power Delivery Chain Unification: use of digital communications to manage is secure data flows and to integrate virtualized information services at low latency throughout the smart grid; enable N-way (not just two-way) flow of smart grid information; provision of integration through advanced networking protocols, converged networking, and service insertion. Note that this layer is based on advanced networking and communication, and in general may be thought of as system unification. In this model, networking plays a foundational role; this is a direct consequence of the distributed nature of smart grid assets.
2) The second tier 520 is:
-
- Automatic Low Level Control 521—digital protection inside and outside the substation, remote sectionalizing and automatic reclosure, feeder level flow control, local automatic voltage/VAr regulation, stabilization, and synchronization; and
- Remote Measurement 522—monitoring and measurement of grid parameters and physical variables, including direct power variables, derived element such as power quality measures, usage (metering), asset condition, as-operated topology, and all data necessary to support higher level function classes and applications.
3) The third tier 530 is:
-
- Control Disaggregation 531—control commands that are calculated at high levels must be broken down into multiple commands that align with the conditions and requirements at each level in the power delivery chain; the process to accomplish this is the logical inverse of data aggregation moving up the power delivery chain, and must use knowledge of grid topology and grid conditions to accomplish the disaggregation; and
- Grid State Determination 532—electrical measurement, power state estimation, and visualization, voltage and current phasors, bus and generator is phase angles, stability margin, real and reactive power flows, grid device positions/conditions, DR/DSM available capacity and actual response measurement, storage device charge levels, circuit connectivity and device parametrics.
4) The fourth tier 540 is:
-
- Fault Intelligence 541—detection of short or open circuits and device failures; fault and failure classification, characterization (fault parameters), fault location determination, support for outage intelligence, support for adaptive protection and fault isolation, fault prediction, fault information notification and logging;
- Operational Intelligence 542—all aspects of information related to grid operations, including system performance and operational effectiveness, as well as states of processes such as outage management or fault isolation;
- Outage Intelligence 543—detection of service point loss of voltage, inside/outside trouble determination, filtering and logging of momentaries, extent mapping and outage verification, root cause determination, restoration tracking and verification, nested root cause discovery, outage state and process visualization, crew dispatch support;
- Asset Intelligence 544—this has two parts:
- asset utilization intelligence—asset loading vs. rating, peak load measurement (amplitude, frequency), actual demand curve measurement, load/power flow balance measurement, dynamic (real-time) de-rating/re-rating, real-time asset profitability/loss calculation; and
- asset health/accumulated stress intelligence—device health condition determination, online device and system failure diagnostics, device failure or imminent failure notification, asset accumulated stress measurement, Loss of Life (LoL) calculation, Estimated Time to Failure (ETTF) prediction, Asset Failure System Risk (AFSR) calculation; and
- Control Federation 545—grid control increasingly involves multiple control objectives, possible implemented via separate control systems. It is evolving into a multi-controller, multi-objective system where many of the control systems want to operate the same actuators. A core function of the smart grid is to federate these control systems that include Demand Response and DSM, voltage regulation, capacitor control, power flow control, Conservation Voltage Reduction (CVR), Electric Vehicle Charging Control, Line Loss Control, Load Balance Control, DSTATCOM and DER inverter VAr control, reliability event control, Virtual Power Plant (VPP) control, and meter connect/disconnect and usage restriction control.
These function classes may support one or more smart grid applications 550. In general, therefore, smart grid networks, that is, the combination of a utility grid with a communication network, along with distributed intelligent devices, may thus consist of various type of control, data acquisition (e.g., sensing and measurement), and distributed analytics, and may be interconnected through a system of distributed data persistence. Examples may include, among others, distributed SCADA data collection and aggregation, grid state determination and promulgation, implementation of distributed analytics on grid data, control command delivery and operational verification, control function federation (merging of multiple objective/multiple control systems so that common control elements are used in non-conflicting ways), processing of events streams from grid devices to filter, prevent flooding, and to detect and classify events for low latency responses, and providing virtualization of legacy grid devices so that they are compatible with modern approaches to device operation and network security.
In particular, there may be a number of types of control, such as sequence control (e.g., both stateless and stateful, typified by switching systems of various kinds), stabilizers (e.g., which moderate dynamic system behavior, typically through output or is state feedback so that the system tends to return to equilibrium after a disturbance), and regulators (e.g., in which a system is made to follow the dynamics of a reference input, which may be dynamic or static set points). Quite often, all three of these are present in the same control system. In terms of electric power grids, flow control is sequence control, whereas model power oscillation damping and volt/VAr control represent stabilization and regulatory control, respectively.
For most control systems, feedback is a crucial component.
Regarding data acquisition, sensing and measurement support multiple purposes in the smart grid environment, which applies equally as well to many other systems characterized by either geographic dispersal, or large numbers of ends points, especially when some form of control is required. Consequently, the sensing system design can be quite complex, involving issues physical parameter selection, sensor mix and placement optimization, measurement type and sample rate, data conversion, sensor calibration, and compensation for non-ideal sensor characteristics.
Additionally, collection of the data in large scale systems such as smart grids presents issues of cycle time, data bursting, and sample skew. There are multiple modes of data collection for large scale systems and each presents complexities, especially when the system model involves transporting the data to a central location. In the typical round-robin scanning approach taken by many standard SCADA systems, the time skew between first and last samples represents an issue for control systems that is insignificant when the scan cycle time is short compared to system dynamics, but as dynamics increase in bandwidth with advanced regulation and stabilization, and as the number of sensing points increases, the sample time skew problem becomes significant.
Data is consumed in a variety of ways and places in a power grid; most of these is are not located at the enterprise data center and much grid data does not enter the data center. Some of it does not even enter the control/operations center, as it must be consumed “on the fly” in grid devices and systems. Consequently it is important to classify data according to the latency requirements of the devices, systems, or applications that use it and appropriate persistence (or lack thereof) must also be defined. Note that much grid data has multiple uses; in fact, it is an element of synergy that has significant impact on smart grid economics and system design (networking, data architecture, analytics) to ensure that data is used to support as many outcomes as possible.
The latency hierarchy issue is directly connected to the issue of lifespan classes, meaning that depending on how the data is to be used, there are various classes of storage that may have to be applied. This typically results in hierarchical data storage architecture, with different types of storage being applied at different points in the grid that correspond to the data sources and sinks, coupled with latency requirements.
Distributed analytics may be implemented in a fully centralized manner, such as usually done with Business Intelligence tools, which operate on a very large business data repository. However, for real-time systems, a more distributed approach may be useful in avoiding the inevitable bottlenecking. A tool that is particularly suited to processing two classes of smart grid data (streaming telemetry and asynchronous event messages) is Complex Event Processing (CEP) which has lately also been called streaming database processing. CEP and its single stream predecessor Event Stream Processing (ESP) can be arranged into a hierarchical distributed processing architecture that efficiently reduces data volumes while preserving essential information embodies in multiple data streams.
In general, distributed analytics can be decomposed into a limited set of analytic computing elements (“DA” elements), with logical connections to other such elements. Full distributed analytics can be constructed by composing or interconnecting basic analytic elements as needed. Five basic types of distributed analytic elements are defined herein, and illustrated in
-
- 1. Local loop 1010—an analytic element operates on data reports its final result to a consuming application such as a low latency control;
- 2. Upload 1020—an analytic element operates on data and then reports out its final result;
- 3. Hierarchical 1030—two or more analytic elements operate on data to produce partial analytics results which are then fused by a higher level analytics element, which reports the result;
- 4. Peer to peer 1040—two or more analytics elements operate on data to create partial results; they then exchange partial results to compute final result and each one reports its unique final analytic; and
- 5. Database access 1050—an analytic element retrieves data from a data store in addition to local data; it operates on both to produce a result which can be stored is in the data store or reported to an application or another analytic element
A sixth type, “generic DA node” 1060, may thus be constructed to represent each of the five basic types above.
Given the above-described concept of distributed analytics, including the database access element 1050 shown in
Notably, the architecture herein may build upon the core function groups concept above to extend grid capabilities to the control center and enterprise data center levels, using the layer model to unify elements and approaches that have typically been designed and operated as if they were separate and unrelated. This model may also be extended to provide services related to application integration, as well as distributed processing. This yields a four tier model, wherein each tier is composed of multiple services layers. The four tiers are as follows (from the bottom of the stack upward), where each of the layers and tiers is intended to build upon those below them:
1. Network services;
2. Distributed Intelligence services;
3. Smart Grid Core Function services; and
4. Application Integration services.
Additionally, the Smart Grid Core Function Services layer 1220 (detailed in
Another way of approaching the layered services stack as shown in
Based on the description above, a layered services platform may be created, which is a distributed architecture upon which the layered services and smart grid applications may run. The distributed application architecture makes use of various locations in the grid, such as, e.g., field area network routers and secondary substation routers, primary substations, control centers and monitoring centers, and enterprise data centers. Note that this architecture can be extended to edge devices, including devices that are not part of the utility infrastructure, such as building and home energy management platforms, electric vehicles and chargers, etc.
Control Command Disaggregation and Distribution
As noted above, grid control operations generally aggregate control commands at a central point in the utility grid, such as a control center, which is inefficient and does is not promote scalability. A great deal of innovation has focused on data aggregation techniques that collect various information/data, reduce its size, and move it toward a central point. However, very little effort has focused on the reverse process: taking a centralized process/function/information, deconstructing it into sub-processes/functions/data, and disseminating it throughout a network.
The techniques herein, on the other hand, provide for control command disaggregation, which takes a generic control command, such as a demand response, and disaggregates it into sub-commands while adding intelligence and distributing the disaggregated sub-commands into the network or sub-network. In other words, command disaggregation breaks a global command, or commands, down into one or more local commands. Command disaggregation may occur in the context of a local conditions assessment. In other words, command disaggregation may occur while taking into account local conditions within the utility grid or network, which may prevent potential conflict caused by multiple controllers (e.g., a grid controller device, a sub-grid controller, and the like) having differing/conflicting objectives.
Specifically, according to one or more embodiments of the disclosure as described in detail below, a grid controller device of a given locality within a utility grid may receive a grid control command and determine a plurality of sub-localities that are to be controlled by the grid controller device. The grid controller may then determine one or more grid characteristics associated with each of the plurality of sub-localities (e.g., local grid conditions such as, voltage, temperature, load, etc.). The grid controller device then disaggregates the grid control command into a plurality of sub-locality control commands according to the grid characteristics of the corresponding plurality of sub-localities, and distributes the sub-locality control commands to sub-grid controllers.
Illustratively, the techniques described herein may be performed by hardware, software, and/or firmware, such as in accordance with the grid-specific application process 348, which may contain computer executable instructions executed by the processor 320 to perform functions relating to the techniques described herein. For example, the techniques herein may be treated as a “control command disaggregation is process,” and may be located across a distributed set of participating devices 300, such as grid controller devices, sub-grid controller devices, and the like, as described herein, with functionality of the process 348 specifically tailored to the particular device's role within the techniques of the various embodiments detailed below.
Operationally, the techniques herein allow for control command disaggregation as an extended network service, illustratively through the grid control disaggregation services of SG core function services layer 1220 in the stack 1200 of
As shown in
For example, consider a system wide demand response (DR) load reduction request that calls for a 50 MW of demand reduction across an entire service area. Generally, DR available capacity is not evenly distributed across the utility grid, and since local feeder conditions vary, it may be necessary to disaggregate the 50 MW DR load reduction control command down to a large set of local DR control commands appropriate to each locality, or sub-locality (e.g., localized feeder sections), where the amount of DR may be as low as a few dozen kW. This type of control command disaggregation may be done centrally (e.g., by a control center); however, in practice, attempts by Virtual Power Plant (VPP) systems to do this have encountered severe problems with scalability. The techniques herein solve these problems by providing disaggregated control commands that are distributed throughout the network. Additionally, control command disaggregation may take advantage of cooperating VPP engines to solve for control solutions over their respective service zones. The size of the resulting optimization problems may then be bounded and solved in parallel locally, instead serially in a centralized engine (e.g., in control center 1510). The techniques herein may also be integrated with substation area balancing, which is emerging as a distributed control approach in the industry, and would also be consistent with the transactive control model being experimented with by PNNL.
In most control environments, supervision and centralized management is typically provided for distributed control commands because most system operators wish to maintain the ability to manage control agents that have been disseminated into the network. However, it should be noted that completely flat central management leads to the problem of impaired scalability. As shown in
This model may be extrapolated to sub-localities 1620 that are controlled by sub-grid controllers 1630, which are controlled by grid controller device 1610. For example, grid controller device 1610 may forward a disaggregated control command (DCC) 1640 to sub-grid controllers 1630, which may implement the command to control a desired aspect of sub-locality 1 1620 or sub-locality 2 1621. The sub-localities 1620 and 1621 may then provide condition feedback to sub-grid controllers 1630 in the form of feedback F1 1622 and/or F2 1624, which imparts intelligence at the local level to the control command disaggregation process. Similar feedback may also move up the chain to the grid controller device in the form of sub-locality feedback SLF1 1642 and/or SLF2 1644.
The multi-tier hierarchical control model 1600 allows this modular template to be applied again at higher levels in the power chain (e.g., from the regional level on up to the control center level); alternatively, it may also be applied down the power chain to various sub-localities, which provides finer control granularity as may be needed to implement a particular disaggregated control command. It will be appreciated that the multi-tier hierarchical control model 1600 provided herein greatly simplifies peer-to-peer messaging when the elements are physically distributed, as is contemplated for smart grids and other large scale physical systems.
Illustratively, grid data sources and data classes may be mapped to control command function classes and represented as control synergy map 1700 as shown in
It will be appreciated that digital closed loop control systems typically assume that measurement, feedback, and control signals are all uniformly spaced in time (i.e., a low latency environment). For large scale systems such as a utility grid, it may be challenging to get the data and signals to the controllers with acceptable latency and time skew, and may put significant demands on the communications networks. The techniques herein mitigate these problems because of the distributed nature of the disaggregated control commands. Additionally, while it is difficult to completely eliminate such latency and time skew issues in a utility grid at scale (e.g., receipt of global state condition data/information may be subject to time skew given the size of the grid), the techniques herein may eliminate latency and time skew issues with respect to local feedback and control signals.
It should be noted that while certain steps within procedure 1800 may be optional as described above, the steps shown in
The techniques described herein, therefore, provide for control command disaggregation and distribution within the network. In particular, the techniques herein alleviate the scaling issue for smart grids at scale, and provide for localized granular intelligence as a control command is sent from a centralized location into the utility grid.
Notably, a layered network services architecture approach addresses complexity management for smart grids at scale, one of the most challenging smart grid design issues. Short term adoption of a layered services architecture allows for efficient transition to new control systems that are hybrids of distributed elements with centralized management. Later, as smart grid implementations approach full scale (in any given dimension), complexity management and the other smart grid architecture issues will benefit from a layered services architecture.
Said differently, now that communications and embedded processing capabilities are becoming available in forms that utility companies can use, a major obstacle in the adoption of distributed intelligence is that utility companies cannot make large changes in their systems in discrete steps. Rather they must go through transitions that can take years to complete. This is due to the nature of their mission and the financial realities utility companies face. In practice, utilities need to transition from centralized to distributed intelligence, and to operate in a complicated hybrid mode for long periods of time, perhaps permanently. This means that the utility service provider needs to be able to roll out distributed intelligence incrementally while maintaining full operations over the entire service area, and be able to modify the distributed architecture appropriately is over time and geography. Simply having a distributed architecture implementation is not sufficient; it needs to be easily and continually mutable in terms of what functionality is distributed to which processing locations in the grid and be capable of coexisting with legacy control systems where they remain in place.
The present disclosure thus presents one or more specific features of a distributed intelligence platform that supports variable topology over both time and geography. The platform provides the mechanisms to locate, execute, and re-locate applications and network services onto available computing platforms that may exist in control and operations centers, substations, field network devices, field edge devices, data centers, monitoring centers, customer premises devices, mobile devices, and servers that may be located in power delivery chain entities external to the Transmission and Distribution utility. These techniques use a communication network as a future-proofed platform to incrementally and variably implement distributed intelligence and thereby achieve the associated benefits without being forced to make an untenable massive switchover or to use a single fixed architecture everywhere in its service area.
While there have been shown and described illustrative embodiments that provide for control command disaggregation and distribution within the network, it is to be understood that various other adaptations and modifications may be made within the spirit and scope of the embodiments herein. For example, the embodiments have been shown and described herein with relation to electric grids. However, the embodiments in their broader sense are not as limited, and may, in fact, be used with other types of utility grids, such as gas, water, etc., or specific types of “smart” networks where appropriate. For example, in addition to utility grids, recent trends indicate that the future will progress towards sensor-actuator based automation in various sectors including buildings, communities/cities, transportation, energy, etc. Experts predict that in the coming decades there will be a fabric of trillions of sensor-actuator devices embedded into our surroundings. This fabric will bring about integrated automation that will greatly improve the efficiency of the environment/resources as well as the quality of living for the human and living being within the environment. In addition, while certain protocols is are shown, other suitable protocols may be used, accordingly.
The foregoing description has been directed to specific embodiments. It will be apparent, however, that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advantages. For instance, it is expressly contemplated that the components and/or elements described herein can be implemented as software being stored on a tangible (non-transitory) computer-readable medium (e.g., disks/CDs/RAM/EEPROM/etc.) having program instructions executing on a computer, hardware, firmware, or a combination thereof. Accordingly this description is to be taken only by way of example and not to otherwise limit the scope of the embodiments herein. Therefore, it is the object of the appended claims to cover all such variations and modifications as come within the true spirit and scope of the embodiments herein.
Claims
1. A method, comprising:
- receiving a grid control command at a grid controller device of a given locality within a utility grid;
- determining a plurality of sub-localities controlled by the grid controller device;
- determining one or more grid characteristics of each of the plurality of sub-localities;
- disaggregating the grid control command into a plurality of sub-locality control commands according to the grid characteristics of the corresponding plurality of sub-localities; and
- distributing the sub-locality control commands to sub-grid controllers.
2. The method as in claim 1, wherein the given locality of the grid controller device is a sub-locality within the utility grid for which a higher level grid controller is responsible.
3. The method as in claim 1, wherein the grid control command is a demand response.
4. The method as in claim 1, wherein the grid characteristics are a grid topology and/or a grid state.
5. The method as in claim 1, wherein the grid characteristics are selected from the group consisting of temperature, voltage, current, phase, power level, power consumption, grid load, time, and number of devices.
6. The method as in claim 1, wherein the given locality or sub-locality within the utility grid is selected from the group consisting of a substation, a secondary substation, a feeder, and a field area router.
7. The method as in claim 1, wherein distributing further comprises:
- distributing the sub-locality control commands into all of the sub-localities or a subset of the sub-localities.
8. An apparatus, comprising:
- one or more network interfaces to communicate with a low power and lossy network (LLN);
- a processor coupled to the network interfaces and adapted to execute one or more processes; and
- a memory configured to store a process executable by the processor, the process when executed operable to: receive a grid control command at a grid controller device of a given locality within a utility grid; determine a plurality of sub-localities controlled by the grid controller device; determine one or more grid characteristics of each of the plurality of sub-localities; disaggregate the grid control command into a plurality of sub-locality is control commands according to the grid characteristics of the corresponding plurality of sub-localities; and distribute the sub-locality control commands to sub-grid controllers.
9. The apparatus as in claim 8, wherein the given locality of the grid controller device is a sub-locality within the utility grid for which a higher level grid controller is responsible.
10. The apparatus as in claim 8, wherein the grid control command is a demand response.
11. The apparatus as in claim 8, wherein the grid characteristics are a grid topology and/or a grid state.
12. The apparatus as in claim 8, wherein the grid characteristics are selected from the group consisting of temperature, voltage, current, phase, power level, power consumption, grid load, time, and number of devices.
13. The apparatus as in claim 8, wherein the given locality or sub-locality within the utility grid is selected from the group consisting of a substation, a secondary substation, a feeder, and a field area router.
14. A system, comprising:
- one or more grid controller devices of one or more localities within a utility grid, each grid controller device configured to receive one or more grid control commands, determine one or more sub-localities to be controlled by the one or more grid controller devices, determine one or more grid characteristics of each of the one or more sub-localities, disaggregate the one or more grid control commands into a plurality of sub-locality control commands according to the one or more grid characteristics of the corresponding one or more sub-localities, and distribute the plurality of sub-locality control commands to the one or more sub-localities; and
- one or more sub-grid controllers associated with the one or more sub-localities, each configured to receive the plurality of sub-locality commands and control the associated sub-locality.
15. The system as in claim 14, wherein the given locality of the grid controller device is a sub-locality within the utility grid for which a higher level grid controller is responsible.
16. The system as in claim 14, wherein the grid control command is a demand response.
17. The system as in claim 14, wherein the grid characteristics are a grid topology and/or a grid state.
18. The system as in claim 14, wherein the grid characteristics are selected from the group consisting of temperature, voltage, current, phase, power level, power consumption, grid load, time, and number of devices.
19. The system as in claim 14, wherein the given locality or sub-locality within the utility grid is selected from the group consisting of a substation, a secondary substation, a feeder, and a field area router.
20. The system as in claim 1, wherein the sub-locality control commands are distributed into all of the sub-localities or a subset of the sub-localities.
Type: Application
Filed: May 30, 2012
Publication Date: Dec 6, 2012
Applicant: Cisco Technology, Inc. (San Jose, CA)
Inventor: Jeffrey D. Taft (Washington, PA)
Application Number: 13/484,042
International Classification: G05F 5/00 (20060101);