Patent Application
20190181647
This patent generally relates to the control of commodity distribution systems, e.g. an electric power distribution system, and more specifically to the use of intelligent autonomous nodes for managing and controlling the distribution system to improve circuit protection and allocation of system resources and ultimately service to end customers.
In general, a distribution system includes one or more sources connected through a distribution network to one or more delivery points. As the commodity (material or energy) is transported through the network, changing network conditions (e.g., load demand, source availability, etc.) or abnormalities (e.g., faults, loss of source, etc.) may develop that can lead to a disruption of the normal flow of the commodity or a loss of the commodity from the system. In order to help minimize the effects of these changes, a distribution system will typically have nodes at various locations throughout the network, which operate to monitor or control the flow of the commodity through the system. It is desirable to not only minimize the loss of the commodity when an abnormality occurs, but also to minimize the number of users who experience an interruption of the delivery of the commodity due to system changes. In order to reduce the loss of the commodity, the nodes in a system may have the capability to respond individually to system abnormalities without coordinating with other nodes. In such a system, nodes can prevent the commodity from flowing through the part of the distribution system where the abnormality exists. However, this system may interrupt service to more users than is necessary to isolate the abnormality from the distribution system.
Failures of the distribution feeder (faults) may occur due to downed power lines, excavation of underground cable or other causes and are typically detectable by sensing excess (short circuit/overcurrent) current, and occasionally by detecting loss of voltage. In distribution systems, it is sometimes the case that a loss of voltage complaint by the customer is the means by which the utility senses the outage, responding by dispatching a crew to isolate the fault and reconfigure the distribution system. The typical devices for isolating these faults are circuit breakers located primarily in distribution substations and fuses located on tap lines or at customer transformers. The substation breakers are generally provided with reclosing relays that cause the breaker to close several times after the breaker has detected an overcurrent condition and tripped open. If during any of these “reclosures”, the fault becomes undetectable, service is restored and no extended outage occurs. Particularly on overhead distribution lines, temporary arcing due to wind, lightening, etc causes many faults. Thus, the majority of faults are cleared when the breaker opens and service is restored on the automatic reclose. Alternatively, after some number of reclosure attempts, if the overcurrent condition continues to be present, the recloser goes into a “lockout” state which prevents further attempts to clear the fault.
Other than manually operated switches, most distribution feeders have no other means to isolate a fault between the substation and the fuses, thus any failure of the feeder results in lengthy, costly, inconvenient and potentially dangerous outages. The primary exceptions to this involve the use of devices known as “line reclosers”, “interrupters” and “automatic line sectionalizing switches” or “sectionalizers”. These are automatically operated devices, well known to those skilled in the art, and are referred to categorically in this document as “fault isolating devices”. The term “sectionalizer” refers to a specific family of automatic, fault isolating devices described below, while the terms “sectionalizing” and sectionalize” are used to describe the process of isolating a faulted section of line, which can be performed by all of the classes of switches described above.
The “line recloser” is typically a pre-packaged, version of the substation breaker with reclosing relay. Line reclosers typically consist of a fault-break switching device with integrated current sensing, plus a control enclosure containing fault detection hardware, control logic, user interface module, and battery-backed power supply. When placed on the distribution line between the substation and customer loads, a line recloser is typically set up with fault detection settings coordinated to operate before the substation breaker trips and to correspondingly prevent the substation breaker from tripping. This has the effect of reducing the number of customers affected by an end of line fault. On very long feeders, the more sensitive settings can be used to protect the feeder from faults of a magnitude too low to be detected reliably by the substation circuit breaker. Multiple line reclosers can be placed on a distribution line in series, although it becomes increasingly difficult or impossible to coordinate their settings such that only the nearest recloser on the source side of the fault operates.
The “interrupter” is typically a pre-packaged breaker and fault relay without automatic reclosing capability. Interrupters are used primarily in underground power distribution systems.
The “automatic line sectionalizer” or “sectionalizer” is typically a prepackaged combination of a load-break switch used in conjunction with a device known as a “line sectionalizer control”. The sectionalizer senses current (and optionally voltage) such that the operation of the circuit and the source-side protective device can be monitored. The sectionalizer is configured to open its switch under certain circumstances when the circuit is de-energized after some number of pre-configured voltage losses have occurred within a brief time interval. The circumstances vary from product to product, but are always based upon sensing of conditions caused by faults followed shortly by voltage losses. Sectionalizers are designed to coordinate with the operation of the circuit's protective devices. Typical sectionalizers are devices such as the Cooper Power Systems Sectionalizer type GV or GW manufactured by Cooper Industries, Inc, or the Model 2800-SC Switch Control manufactured by S&C Electric Company.
Various types of distribution automation systems have been developed to isolate faults and reconfigure the distribution system to provide service to the maximum number of end users. These types of systems include various combinations of centralized controls, distributed controls and intelligent autonomous controls. In such centrally controlled systems, each node may communicate with a central control location which gathers information from each node and coordinates a system-wide response. The central controller typically maintains a detailed map of the system topology, and this map must be updated whenever the system is reconfigured or new nodes are added. This can make such centrally controlled systems less reliable and more difficult and costly to implement and maintain. Additionally, for small systems with few nodes, the need to include a central controller can significantly add to the cost of the system. Furthermore, once an abnormality is rectified, the nodes typically must be transitioned to a normal state or to a specified state. Once the abnormality is corrected, it is generally desired to place the nodes in the original configuration or a specified configuration, at present this is typically done manually.
Intelligent, distributed control methodology is illustrated in U.S. Pat. Nos. 6,018,449; 6,111,735; 6,243,244 and 6,347,027. While these systems may be generally suitable to perform their intended functions, it is advantageous to determine how to optimally reconfigure a complex distribution circuit while preventing overloading of any portion of the circuit; i.e. allocation of system resources. This becomes particularly difficult in circumstances where the circuit branches out (bifurcates) such that multiple load-side switches could attempt to simultaneously pick up additional load and overload the circuit.
This patent describes methods and systems for controlling a commodity distribution system, e.g. an electric power distribution system. The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of particular applications and their requirements. Various modifications to the described embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to any particular embodiment shown, but is to be accorded the widest possible scope consistent with the principles and features disclosed herein. For example, the present invention is applicable to various distributed commodities in addition to electricity such as fluid flow etc. Further, while illustrative electrical systems utilize switch locations at various nodes and locations, it should be realized that in particular embodiments, these illustrative switch locations are any one of a variety of devices including reclosers, breakers, sectionalizers or other protective devices.
Each of the sources and nodes may incorporate processing capability, e.g., a processor, with associated memory for retaining one or more control programs and data. The processor is operable in response to a control program and available data to control operation of the source or node to facilitate the efficient distribution of the commodity. Each of the source and nodes may also incorporate one or more forms of communication capability, including wired or wireless communication devices. For example, each of the sources and nodes may be capable of linking to a wireless communication network using a suitable network protocol such as 802.11-based standards, linking to a power line communication network via over-power-line protocol, using radio communication in the unlicensed frequency spectrum, using other communication techniques and protocols and, of course, various combinations thereof.
In accordance with the herein described embodiments, at least selected ones the sources and nodes of the distribution network operate autonomously, i.e., with distributed intelligence. The sources and nodes may team their operation, which is preferred such as described in aforementioned United States patents and in U.S. patent application Ser. No. 11/516,279, the disclosures of which are hereby expressly incorporated herein by reference for all purposes.
For this type of interdependent wide area networked process and control system, it is beneficial to implement and maintain local copies of a replicated database containing, for example, lists of all system devices, their static resource capabilities, their real-time resource utilization, and a table describing the interconnection of all system devices. A copy of this database, herein termed the Netlist, may exist at key intelligent, “Netlist enabled”, controls in the interconnected system. The real-time dynamic parameters of every device in the system may be constantly updated via a communications infrastructure. Therefore each Netlist enabled device can always have the real-time status and available resources of every other device in the control system.
Individual interdependent wide area networked process and control devices can be greatly benefited in their efficiency, effectiveness, and capabilities when they have ready access to the status and resources of the other process and control devices in their system.
Given each such device maintains a database of the real-time status and available resources of every other device in the system it is possible to quickly modify system function due to remote changes in system status and resources.
Specifically, for various network types, such as, without limiting the generality of the types of networks, networks associated with distributed intelligence, power distribution resource management systems the Netlist enabled devices facilitate:
The Netlist, database, utilizes a communications medium to enable its value as an aide to process and control.
In one embodiment the Netlist consists of a distributed dataset that is uniquely suited to a distributed intelligence system such as IntelliTEAM SG available from S&C Electric Company, Chicago, Ill. Other embodiments of a Netlist consist of a single dataset at a central processor. This centralized form of Netlist does not readily facilitate the fast localized parallel processing as is possible in a distributed system. The distributed Netlist therefore has potential advantages in reliability as well, having no central point of failure.
As illustrated generally in
The interconnection relationships are listings of devices with common connection, such as all devices connected to the same conductor in a power distribution system or all devices connected to the same fiber optic cable or devices all on the same Ethernet subnet or all devices providing resources for a specific purpose or to a specific consumer.
The enabling communications infrastructure can be of any type and may include serial, wired or wireless Ethernet, optical fiber, radio, telephone, etc. Each “Netlist enabled” device is able to communicate changes of its status and resource availability to every other “Netlist enabled” intelligent device in the system via the communications infrastructure. This allows each “Netlist enabled” device to maintain its copy of the real-time status and resources of the Netlist component's dynamic parameters that it has received over communications.
Generally, the Netlist approach to commodity distribution system infrastructure includes: load Balancing; load shedding; Volt/Var management; control of discretionary customer loads; management of energy storage systems; management of distributed energy production; local TCC selection; return to normal manager; close one restore all (CORA); self healing communications system; non-operational device reporting and loss reduction optimization.
The features of Netlist and other distribution network functionality enabled by the Netlist are demonstrated by way of several examples. While in the embodiments the functionality is enable by the Netlist, other means of enabling the functionality can be envisioned and employed. Therefore, while the examples utilize the Netlist in their description, this, again, is done to demonstrate one way of enabling the described functionality.
The following is a brief summary of features that are possible in an automated distribution system that incorporates a Netlist architecture, and are described by way of example in more detail below:
The aforementioned US patents and patent application describe a basic architecture for distributed automation systems. Addition of an agent based approach, with distributed intelligence and peer-to-peer communications, along with Netlist further enable the herein described new functionality. A new and very important component is being added though, the Netlist. The Netlist is a key to moving from a line section view (the Team as used in the aforementioned patents and applications) to a much wider distribution system view.
Referring again to
An example of the use of the Netlist is CORA, rapid self-healing or generally a process by which a switch isolating a fault near the source end of a circuit can search much further out the circuit to find an appropriate alternate source tie switch (checking loading, capacity, and state), and then directly address that switch to request restoration. That is, the switch can search through the Netlist data to identify a resource or resources that will best provide service restoration.
The Netlist may be created using a PC-based management application that allows graphic circuit creation and component definition as well as address and interconnectivity data entry. Once created, suitable communication methods, such as network propagation methods, may be used to distribute the Netlist to each Netlist enabled device in the distribution network. Other methods, such as automated creation of the Netlist from distribution system definitional data can be employed.
To facilitate creation, distribution and updating of the Netlist, a network component, e.g., a Runner, can be defined. The Runner is an entity that is created on an interval basis (possibly once a second) at each source switch device and is transmitted to every other switch device in turn along the circuit until it reaches the opposite source. Along the way the Runner collects changed data at each device and hands it off to every other device. Since a Runner is created at every source device it follows that Runners transverse the circuit in at least two directions at once in an effort to keep all data up to date. Also, since there are usually more than two sources, Runners may divide at branches in the network to follow multiple branches of the circuit. While following the electrical path may be efficient, there may be more efficient ways the Runner(s) may transit the network. For example, Runners may follow defined grids or other rules based on geography, communications or an algorithm. The Runner also has the capability to provide real time view of system variables as the same are collected within the system, and show actual and changing switching conditions as the system reconfigures. It also can collect and report loading data. The Runner provides the collected data to each node within the system, and the data may be stored within the Netlist and/or other memory at each node.
A robust communication protocol as a generic data transporter is required the provides sufficient frame size, efficient header and object definition, efficient error, CRC checking, write functionality and dynamic communication media adaption is preferred. A communications protocol that specifically transports generic data between peer devices improves data propagation rates. Such a custom protocol can multiplex on the same channel with DNP, much the same as “Local protocol” multiplexes with DNP. This can eliminate the need for redundant parallel communications systems. While the DNP3 protocol may be limited in offering the above feature, it may be possible to adapt it to meet these requirements. It may further be possible to define a new protocol, e.g., a “DNP4” or adapt another existing protocol such as the IEC 61850 protocol. Implementation of the herein described functionality does not require but does require a suitable peer-to-peer communication protocol such as defined in the aforementioned patents and pending applications, DNP or suitable adaptations of the same or other suitable communication capability such as the SpeedNet radio system available from S&C Electric Company.
The mobile autonomous software agent architecture may be implemented using existing or newly developed standards. One possibility for an open, existing standard is JADE (Java Agent Development Framework). According the website (http://jade.tilab.com/) “JADE is free software and is distributed by Telecom Italia, the copyright holder, in open source software under the terms of the LGPL (Lesser General Public License Version 2). It is a software framework that is fully implemented in Java language. It simplifies the implementation of multi-agent systems through a middle-ware that complies with the FIPA specifications and through a set of graphical tools that supports the debugging and deployment phases.
It may be desirable to use or create an open standard for agent containers in field devices. Such a general framework may allow implementation on a broader array of devices. Such a framework may be, at a high level, functionally similar to the browser/DOM/Javascript model on a PC. A mobile agent would have access to facilities at a field device through a closely controlled process similar to how a web page has access to PC facilities through a web browser.
Still another possibility is to create a virtualized EOS. Essentially this means to create a CCP hardware emulation layer on a PC so that the distributed network operating system and applications can run in a virtual CCP environment under existing operating systems such as Windows or Linux. This method has added benefits in creation of PC based test and simulation programs. The ability to run any number of instances of devices in one box could be very powerful. Field communications of any quality and form could also be simulated through inter-process communications.
While details of existing distribution automation, fault isolation and service restoration technology is described in the above-referenced patents and patent application, a brief background and definition of terms is useful.
As described in the above-reference patents and patent applications, existing distribution automation functionality is based on three key building blocks:
These building blocks are implemented using:
It should be understood that the logical operation of the distribution automation system is based on the concept of the line section rather than the individual physical devices that surround the section. Initially, in keeping with the “Team” analogy, the line section was called the “Field”. The Field is bounded by Team Members (switches or nodes on the line section), and the Coach moves freely between the members executing tasks. With this in mind the execution of logic is no longer associated with a single device, but rather a number of devices within the Team, each becoming a temporary container for running the Field/Coach process.
The Coach is a software agent. In fact it can be considered a Mobile Autonomous Software Agent. It has the ability to send itself to any location within its Field, execute the code it deems necessary, and cause physical action to be taken in real-time. The Coach does not carry the executable code with it when it travels. Instead it carries an execution stack. The executable code is actually housed in the Team Member containers, presently identical in every container. This was done for communications efficiency.
For ease of discussion the Coach carries the following items:
When the Coach arrives at a Team Member it unpacks the Briefcase, updating the local database information, and starts executing the tasks (logic/code) on the Clipboard from where it left off at the last Team Member. The Coach can dynamically modify the execution stack based on the local conditions, or events received from elsewhere, and may stay at this Team Member for some time, or may move off to another Team Member, all based on those present conditions and events.
The events just mentioned are components of the process. Events represent changes that occur in real-time throughout the Team, and are distributed to all Team Members with the intent of quick and decisive action by the Coach. The Coach collects events at every Team Member and converts those events into tasks that are executed and can modify the overall execution of the Field process. If an event was received from another Team Member, and must be executed at that Team Member, the Coach will pack up the Briefcase and the Clipboard and will transmit itself to that Team Member for continued execution.
Every switch location can be a member of from one to several Teams. The number of Teams depends on the type of device and the location of that device in the circuit. Typically the installation will be a single. These devices can be a member of one or two Teams: two if this location is mid-circuit; one if this location is either at the beginning of a circuit, or represents the last switch on a radial feeder.
Allowing every switching location to be a member of multiple Teams means that there are several Coach (or agent) processes running in parallel in each control. Each Coach process is completely independent. Management of the Coach life cycle, the events, the tasks, the Briefcase (database), and the Clipboard (execution stack), are unique to each active Team. In fact, a strict rule may be employed preventing Coach processes to directly interact or share data. Another layer of software, known as the Player, is used to facilitate this interaction.
An aspect of the load transfer and circuit reconfiguration process is coordination. This would be coordination of many independent devices and processes over a wide geographic area. The Player is a key component of this coordination because the Player enforces a “Two Coach Rule” of the distribution automation system. The Two Coach Rule states that for any critical operation, such as closing a switch, both Coaches must be present and must agree (through a number of details) that the switch can be closed. The Player is also allowed visibility into Field data for all the Teams at that location. The Player is a static entity that is normally sitting idle. When necessary Coaches request action from the Player (such as closing a switch) by placing tasks on the Player's single execution stack, and the Player can affect the action of each Coach by placing tasks back on the Coach's execution stacks directly, or by creating events that are sent out to reach the Coach.
The Player also interacts with a higher level process called the Contract Agent. The Contract Agent is a single static process that exists at each Team Member, and has the responsibility to request, verify and maintain contracts. Contracts are a configurable feature that are designed to guarantee reservation of portions of capacity available from an alternate source. Primarily intended for bifurcated circuit situations where multiple contingency events could otherwise result in overload conditions, the Contract Agent process insures adequate capacity exists from the alternate source itself prior to restoration.
The foregoing described existing distribution automation restoration processes may be continued in the network and may even continue to be the primary response to outage events (due to the ability to coordinate numerous alternate sources) within the distribution network. In this regard, the distribution system is multi-mode having at least a first mode of operation and a second mode of operation. If the first mode of operation is the existing distribution restoration process, the second mode of operation may be CORA, which may be implemented and can be an effective and often faster alternative for many installations. The first and second modes of operation may be different modes of operating and controlling the commodity distribution system, adaptations of existing distribution restoration processes or CORA and CORA-like processes and combinations thereof. More than two modes of operation may be provided. The modes of operation may be user selectable, dynamically selectable or selected in real time in view of current system conditions, such as availability and capacity of sources, or the like.
As noted above, methodology of CORA is in intent to close one switch to restore all load, but generally may be employed to open a minimal number of switches to isolate a fault and to close a minimal number of switches to restore service. While this method bypasses many of the features of existing restoration schema, such as described in the above-reference patents and patent applications, CORA can dramatically decrease restoration times. When CORA is enabled but unable to restore load though, possibly due to inadequate capacity or other trouble, a fall back may be to utilize the existing restoration operations. Hence, CORA may be the first operating mode and the existing restoration operations the second operating mode employed as a fall back.
CORA is similar to the Contract Agent described in the above-referenced patents and patent applications in that it, in one implementation it is a single static process that exists at every network node (Team Member), it interacts with other CORA agents to effect an operation, and it is a higher level process that interacts locally with a node (the Player). CORA is activated at the downstream isolating switch to find a tie point switch, and CORA logic also executes at the tie point switch when a request is received. It is programmed as an application task and is running in all enabled nodes (team members) at the prescribed interval all the time.
The interaction of CORA begins at the Coach level when a fault isolating event occurs. The isolating event itself is based on protection settings, sectionalizing settings, or if necessary (on the downstream side of the fault) the operation of the Coach. If configured to do so both the source side switch and the load side switch can trip open at the first indication of fault allowing for a very short outage for customers on the unaffected portion of the circuit. More likely though the devices are coordinated in such a way that the downstream switch will be opened only after the upstream switch locks out and the Coach requests the open operation. Note that a further option could be for a communication to cause the downstream unfaulted switch to open after the first trip of the upstream protective device even though the upstream device will continue to reclose and test the line.
The normal operation of existing distribution automation systems after the downstream switch opens would be to open all other downstream switch locations (if they didn't open on their own) in preparation for closing one switch at a time restoring service one line section at a time back to the isolating point. With CORA enabled this functionality is intercepted prior to opening any other switch. The Coach logic is instead redirected to a new task to initiate CORA. However, if CORA is unable to restore load the Coach remains in a state fully prepared to restart operation according to the existing logic.
The enabled state of CORA may be based on both user configuration and internal preparedness. First, CORA may and typically will be user selectable. It is also selectable on a switch-by-switch basis so that this form of restoration can be used only where appropriate (such as where plenty of alternate source capacity is available). Second, CORA requires that the associated Team (or Teams) be in a ready state with no error conditions. If CORA detects trouble it will use Coach event processing to inform the Coach that CORA should not be used at this time. CORA also uses Coach event processing to put CORA back into an active state.
CORA may not be active after startup until all Team functionality is ready. After an isolating event, with CORA active, the Coach logic is redirected to a new task as mentioned above. This new task signals to the Player layer in the same way the Player is signaled to operate a switch. The Player layer has direct interaction with CORA rather than the Coach in order to coordinate the possible multiple Coach signals. This signaling is in the form of requested Player tasks. After requesting the Player task the Coach expects to see a signal back indicating the status of the CORA initiation. If successful the Coach can continue with other branches of the same circuit, if they exist, either starting CORA or alternate restoration as configured. If initiation is not successful the Coach will immediately begin alternate restoration at the location.
The Player task for initiating CORA will directly call a CORA initiate function. The Player will pass CORA the two Fields associated with this Team member location. The Player will expect a return value of whether CORA will attempt to restore load. If the response is good the Player will enter a waiting state, expecting to eventually receive an indication of final outcome. If either the initiating function call returns not good, or the eventual outcome is negative, the Player will inform the Coaches of the trouble.
The initiating CORA function will interact with the Netlist to find an appropriate tie switch to close. CORA passes to the Netlist the Field identification of the Field on the downstream side of the switch location (i.e. the last section of the restored circuit if the tie switch is able to close). The Netlist uses this as a starting point to search for a tie switch. The response from the Netlist is an RTU address, switch position number, available capacity and trouble indication. CORA can then check for a valid tie switch with adequate capacity and no trouble. If all is well the CORA initiating function will register this long-distance peer device with suitable messaging, e.g., DNP, and request that a CORA message be delivered to this device. CORA at this isolating switch will then enter a waiting state.
A safety timer may also be started when the CORA message is sent. If this timer expires prior to receiving confirmation of tie switch operation then CORA will stop execution and return control back to the Player and the Coaches.
Also CORA communication may use the same facilities as all other parts of the existing distribution automation system. Messages are sent, received and managed through a combination of IntelliTEAM functions, and at a lower level, communication functions. The CORA message contains at least:
CORA at the tie switch is continually poised to take action whenever a CORA request is received. At the tie switch CORA will again check the applicability of this location for restoring the load. This is necessary in case local data has changed since the last time the Netlist at the requesting location had been updated. If this location is able to restore the load CORA will ask the Player at this location to close the tie switch. Here again the Player is the central coordinating point for local operations.
Whether this location was able to restore service to the circuit or not, CORA will address the original requesting switch location and send a status message back. CORA at the requesting location will receive the message and inform the Player and the Coaches appropriately, allowing the process to stop, or taking further action to restore load.
With reference to
Load Balancing and Load Shedding
As can be seen from the foregoing examples and appreciated that under various possible operating conditions may occur, a possible result of the CORA-type restoration operating mode is that load may be restored from a single source, even if multiple alternate sources were available. This has the potential of overloading the single source. Therefore, a third operating mode, a post-restoration operating mode may be employed to examine loading and capacity conditions once all load is restored, and then look for closed-transition methods of distributing the load more evenly. However, more than a third operating mode being a post-restoration operating mode, load distribution can be constantly monitored to look for more efficient, more reliable, and less costly configurations of circuit resources. With load balancing, the third-operating mode may be active at the same time as either the first or second operating modes as well as post restoration, and the circuit may automatically move from a normal state to a more optimal state at any time it is allowed based upon a user configuration setting.
During system configuration, Team loads may be prioritized. For example according to the following priorization schedule from 1-10. This schedule may then be used post-restoration to assist load balancing and load shedding.
Additional configuration settings may include whether load may be shed “open”, i.e., load may be transferred to adjacent feeders using only an open transition or “closed” i.e., load may be transferred to adjacent feeders using only a closed transition.
At
Once the overload situation is overcome, the system may then attempt to pick up Teams not being serviced. At
Assigning different load priorities to the Teams would result in different loads being picked up or shed, and hence, different switches at the various nodes being opened or closed.
New Normal and Return to Normal
Post restoration and following load shedding/balancing, the distribution will likely be in a substantially different configuration than is its “normal” state. The term “normal” state implies these other states are abnormal or not desired. This is not the case, and the term is used for convenience. Existing distribution systems are configured with what is considered the normal state of each node in the system, e.g., switches in a Team, and the role each switch plays in the Team (Src/Sub, Load/Tie, etc.) when the Team is in its normal state. When an event occurs that causes reconfiguration a number of switches change state and change their roles. These changes don't prevent continued reconfigurations from occurring though. If a second contingency event takes place the present state of the system is used to find yet another configuration to restore as much load as possible.
“Normal” is then the original state of the system, but not necessarily the starting point for any reconfiguration. However it is not necessary to have a state called “normal.” In fact, “normal” could be replaced with a continuously optimizing algorithm that always configures the distribution system as it deems most fit.
However, system operators may still expect the distribution system to be configured in a predetermined manner (provided emergency conditions don't exist). The first reason for this expectation is safety in knowing the present state of the system. Beyond safety there are engineering reasons, internal political reasons and legacy reasons why there is a normal distribution state. These reasons may be overcome in the future, and hence the desire to provide now the capability for continuous system optimization.
For now, “normal” is still where the distribution automation returns the distribution system when all else is stable, even if this is not the most optimum configuration. Load balancing is still necessary; however, considering the multitude of times when the distribution system is not stable. For example, with CORA and as demonstrated in the example of
A load balancing algorithm may then have degrees of action it will take, first based on user configured parameters, and second on the real world conditions. Possible user configurable settings might be:
Strategies such as these could be compared with strategies on the capacitor control, though different in scale. They may be allowed to only operate within a specified timeframe, only operate once or a limited number of times, or have other restrictions and overrides that prevent the distribution system from getting too far out of human control.
The idea of load balancing “strategies” implies that there is a unified view of the load balancing system, possibly a single point of interface. It might even imply centralized control algorithm. While this is the impression that might be given (and probably should be given from an operational perspective) the actual implementation will be consistent with the distributed logic model and enhanced with additional logic called for purposes of this disclosure the Commissioner and the Time Loading Curve (TLC).
The Commissioner is a mobile autonomous software agent, in many ways similar to the Coach, but with new responsibilities and a more global view. The Commissioner travels between, and executes in, the sources that are available to the distribution system, preferably on a communication backbone, e.g., a fiber backbone (though a secondary route through a mesh radio network can be used if the backbone is lost). Data the Commissioner uses is a combination of local data (substation RTU, etc.), Netlist data from the distribution system, and user input/configuration.
The Commissioner is ultimately involved with the following activities:
The hardware associated with the Commissioner can be either a universal interface module (UIM)-style S&C Electric Company device, or if an open standard is adopted, a 3rd party substation RTU. The platform must provide adequate resources for a very communications intensive application.
As with the Coach, the primary advantages of the mobile autonomous agent architecture are its natural coordinating ability, and its inherent security (no single source of failure/attack). Execution of its algorithms can occur at any location, i.e., any node in the distribution system, but may be limited only to occur if the Commissioner is present. Algorithms will be included to handle failed communication and damaged hardware contingencies.
The TLC is a relatively slow process by which loading and capacity predictions are made locally at each system node (Team Member). It is the general monitoring component of the load balancing process. Some key points that may be included in TLC logic are:
Through a combination of the TLC processing and the algorithms run by the Commissioner a process is created that is essentially predictive load manipulation based on a distributed GIS (Geographic Information System).
To perform the load transfers themselves the Commissioner will coordinate with the Coaches through a series of event messages. Coaches will in turn coordinate with their resources to operate switches and relays, potentially making settings group changes or other device specific activity.
One additional action a Commissioner might take if conditions require is overload sharing (or rolling overload). This is the managed movement of an overload condition between a number of sources when all sources are close to or over their maximum capacity. In this case a portion of load will be rotated around so that no source is overloaded for an extended period.
While load balancing and load shedding may be an automatic feature that changes the circuit configuration based on sensed conditions, permanent changes to circuit configurations are commonly performed by system engineers and operators to account for new loads and new facilities. Historically this has been difficult to manage due to the configuration changes needed at each related control in the field.
Here, as with load balancing, it is important to recognize that a circuit configuration state called “normal” is required. Two potential methods to handle the reconfiguration are: i) a scripted automatic reconfiguration, and ii) a manual reconfiguration followed by an “accept as new normal” signal. Both may be implemented and the operator can choose between using one or the other based on integration with their normal operating procedures.
Scripted automatic reconfiguration shares functionality with site acceptance testing processes described below. A sequence of operations is written into a script and the script is loaded into the appropriate field devices. A script interpreter is included in each field device for the purpose of running scripts made for various reasons. The script execution at each of the applicable locations is coordinated based on GPS time. At a specified time all devices begin the execution that will put those devices in their new states in a carefully choreographed sequence. When complete the new state of the system is accepted as “normal”.
The creation of these scripts may be a product of the Testing/Setup/Analysis Application. Operation of these scripts can also be easily lab tested in the application using an Instant Replay type of process.
The second method is manual reconfiguration followed by signal to “accept new normal”. With this method the choreographed script operation is simply replaced with human operation. Through suitable communications, e.g., SCADA, or local operation utility personnel reconfigure the field devices as required. Once complete a command is sent that instructs all devices to accept their new configuration as the normal configuration.
Given the load balancing features mentioned earlier, with an additional layer of logic and the necessary information the distribution system could coordinate the use of co-generation, micro-generation, storage and other alternate/renewable energy sources within the distribution system. When necessary the distribution automation could even make use of these sources to island blocks of load.
To attempt to maximize a variable resource like wind or solar the distribution automation may provide the following functions:
Additional distribution automation functionality in combination with storage or dispatchable generation:
Additional distribution automation functionality in combination with storage or dispatchable generation with distributed generation:
The storage will tell the distribution automation when there is too much generation within the island, the distribution automation will disconnect (curtail) generation according to the generation priority.
Site Acceptance Test
To assist the ability to manage these new features of distribution automation there may be a PC based application that is involved with the testing, setup, and analysis of the system. Such an application may take the form of a system designer and performs the tasks necessary to support the distribution automation test system.
The functions of the distribution automation designer application may include:
The distribution automation designer may also include:
An example of this last item, detailed performance analysis, may include the distribution automation designer calculating CMI, SAIDI, SAIFI or CAIDI, and saved minutes of interruption. This would be possible by entering the number of customers in each team as a part of the configuration. Perhaps it could even include downstream fuse operations by watching the fault current and breaking out the number of customers connected on fused laterals.
Referring to
The distribution automation site automation testing (SAT) tool provides a means to configure various circuit events and demonstrate the distribution automation response to them—all on an actual field deployment of automation-enabled controls. This tool provides an ability to extend the usual Factory Acceptance Tests (FATs) conducted on distribution automation test systems to the actual customer system deployed on the customer's circuit utilizing the communications system. The supported circuit events at least include faults and losses of voltage (including losses of substations). The emulation of those events are such that the distribution automation operates exactly the way it would in response to those same “real”, non-emulated events. Furthermore, as the distribution automation is a system that is highly dependent on Peer-to-Peer communications, any acceptable SAT solution should introduce as few SAT-specific communications during the test as possible, preferable none at all. Finally, a SAT solution should provide conclusive feedback as to whether the test succeeded or failed (that is, did the distribution automation transfer/return to normal correctly and on time), along with a summary of the distribution automation decisions and operations, at all participating controls.
A PC-Based GUI program (referred to in this discussion as the SAT Manager) is used by the user to configure the SAT scenario. This includes the controls included in the test and the circuit conditions/scenario used for the test.
The start time for the SAT test is configured as part of the SAT input and the control's GPS (or user) synchronized time is used to start all the scripts at the prescribed start time. Special enabling logic in each control runs the script and presents the processor running the distribution automation logic with the analog and digital inputs based on the defined sequence of circuit conditions and/or actions. The actual distribution automation logic is exercised to perform the test. The switch operations resulting SAT scenario and the distribution automation restoration logic can either be virtual or real based on the user's choice. After the SAT is complete, the SAT Manager collects the relevant event logs and information from each control over the communications system, collates and analyzes the results which are then presented to the user. For example, a data trap may take control of messaging between the restoration logic processing and the device control to collect and communicate to the SAT Manager. The distribution automation results can presented in tabular form or also can be provided as a graphical “Instant Replay” of all the switch conditions and operations as a visual confirmation of the test results,
The SAT permits validation of actual system operating mode logic and may be performed using the actual device controls and application algorithms. Additionally, the actual device settings are used, and alternate device settings may be tested. Communications connectivity and stability can be tested and verified and actual live messaging between nodes viewed or later reviewed.
While the invention is described in terms of several embodiments of commodity distribution systems and corresponding methods, it will be appreciated that the invention is not limited to such systems and methods. The inventive concepts may be employed in connection with any number of systems, devices and methods for providing coordinated distribution system protection.
While the present disclosure is susceptible to various modifications and alternative forms, certain embodiments are shown by way of example in the drawings and the herein described embodiments. It will be understood, however, that this disclosure is not intended to limit the invention to the particular forms described, but to the contrary, the invention is intended to cover all modifications, alternatives, and equivalents defined by the appended claims.
It should also be understood that, unless a term is expressly defined in this patent using the sentence “As used herein, the term ‘______’ is hereby defined to mean . . . ” or a similar sentence, there is no intent to limit the meaning of that term, either expressly or by implication, beyond its plain or ordinary meaning, and such term should not be interpreted to be limited in scope based on any statement made in any section of this patent (other than the language of the claims). To the extent that any term recited in the claims at the end of this patent is referred to in this patent in a manner consistent with a single meaning, that is done for sake of clarity only so as to not confuse the reader, and it is not intended that such claim term by limited, by implication or otherwise, to that single meaning. Unless a claim element is defined by reciting the word “means” and a function without the recital of any structure, it is not intended that the scope of any claim element be interpreted based on the application of 35 U.S.C. § 112, sixth paragraph.
This patent is a continuation of U.S. patent application Ser. No. 13/522,482 filed Sep. 25, 2012, which application claims benefit of earlier filed U.S. Provisional Patent Application Ser. No. 61/296,446 filed Jan. 19, 2010 and U.S. Provisional Patent Application Ser. No. 61/313,597 filed Mar. 12, 2010, the disclosures of which are hereby expressly incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61296446 | Jan 2010 | US | |
| 61313597 | Mar 2010 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13522482 | Sep 2012 | US |
| Child | 14877401 | US |
