Reconciliation of BCCS and WSM with Integrative Nod ...



[pic]

Reconciliation of BCCS and WSM with

Integrative Node-Breaker Method

By

Node-Breaker Subgroup of the

Modeling SPS and Relays Ad-Hoc Task Force (MSRATF)

Western Electricity Coordinating Council

August 20, 2014

Introduction

Technical Studies Subcommittee (TSS) formed the Modeling SPS and Relays Ad-hoc Task Force (MSRATF) in August, 2012 in response to findings and recommendations from the Southwest 2011 disturbance, and to achieve broad improvements in transparency between Transmission Owners (TOs), Generator Owners (GOs), Generator Operators (GOPs), Transmission Operators (TOPs), Transmission Planners (TPs) And Planning Coordinators (PCs), and Reliability Coordinators (RCs).

To aid in the effort of improving transparency members of the Western Electricity Coordinating Council (WECC) and Peak Reliability would like to reconcile the WECC base cases with the West-wide System Model (WSM) that is used by Peak Reliability. The WSM is an Energy Management System (EMS) model of the form typically used in real-time operations. The WECC base cases are power-flow models of the form typically used in system planning. Since both models represent much of the same physical equipment, reconciliation of the models should streamline the ability to make comparisons of WECC base cases and WSM cases, and allow validation of both cases by ensuring that a wider audience is using and examining the models. Improvements that can be derived from comparing the WECC base cases with the WSM include; (1) understanding and resolving differences between cases, and (2) avoiding duplication of effort by mapping the current transient stability models from WECC base cases into WSM snapshots. However, since each model includes details incompatible with the assumptions of the other model, some debate exists as to whether the models can be reconciled without loss of functionality in one model or the other (Figure 1).

[pic]

Figure 1: WMS and WECC Base Case data intersections

The node-breaker modeling detail in the WSM, typical of EMS, is perceived as the significant barrier to reconciling the model. Refer to section 1 of the appendix for a detailed description of node-breaker modeling. An equally significant challenge is presented by the different naming used by the two models. In this paper, when referencing node-breaker modeling, “name(s)” refer to invariant identifiers of elements and are used to link the objects in the model to external functions, including references in operating procedures; and asset data and automated contingency files used in planning (Figure 2). Refer to section 2 of the appendix for additional details on “names”.

[pic]

Figure 2: Links between intersecting data, and related non-intersecting data

The purpose of this paper is to outline a method that could be used to move the WECC base cases toward the node-breaker model. The method of incorporating node-breaker connectivity models in WECC base cases being proposed by MSRATF in this paper is what was being called the hybrid method, and now is more accurately called the integrative method. This method transitions from the current bus-branch model to a node-breaker representation by enhancing sections of the bus-branch model (i.e. adding node-breaker modeling detail to bus-branch representation). Inserting the breaker-node models in a substation by substation approach will take a significant amount of time to fully transition the entire WECC base cases into a node-breaker model. This proposal is a transition from the suggestion made in the previous paper (“Node-Breaker White Paper”, January 22, 2014”).

The Node Breaker white paper originally proposed reconciling the two models by replacing the base topology for WECC base cases with node-breaker topology exported from the WSM. This paper presents a refinement on that proposal, using an integrative approach (called integrative method in this paper) which imports the node-breaker modeling used in the WSM into the WECC base cases while preserving the existing WECC base case naming which is essential to existing dynamic data files and automation files.

Why Use An Integrative Method

Several shortcomings of the full-replacement approach were identified with further analysis, related to both loss of functionality (Figure 3) and procedural limitations.

[pic]

Figure 3: Planning loss-of-functionality from replacement approach

The major shortcomings driving the recommended integrative approach are:

• Data sharing concerns; the WSM data is restricted under a non-disclosure agreement that many users of WECC base cases are not able to sign; it would impose untenable limits on what WECC base cases could be used for and to whom they could be distributed.

• Switching to an integrative method puts the responsibility of updating and maintaining the models in the hands of the data owners. It is the responsibility of the data owners to update and maintain their models in accordance with the Data Preparation Manual. A full or partial insertion of node-breaker (connectivity) data in the system can be done to the extent that the data owners agree to the change; however, the owners will continue to be responsible for the accuracy of the models of their equipment.

• Data that is important to the planning community and maintained in the bus-branch models would be lost through a full replacement with the WSM model. This includes the topological data currently in the bus-branch representation. The integrative method allows TOs to keep their topological representation of substation buses while inserting detailed connectivity data for each bus, such as bus arrangement and bus segments, branch connection, breakers and switches.

• Descriptions of contingencies can be given in bus-branch format, or as a label (a branch label, bus segment label, etc.), or by specifying the breakers to open. The system simulation software will need to support this by retaining bus-branch data and linking breaker-node data to it. The desire to retain static identifiers for topological nodes (or buses) may be a transitional desire. In the long term we would recommend that engineers reference elements using a label of the element itself instead of using static bus identifiers as an identifier of other elements. This is described in further detail below, and in section 3 of the appendix.

• Intentional modeling differences such as systems that are equivalenced in WSM cases would need to be identified and expanded if the WSM model were used as the starting point.

For similar reasons, the approach of reconciling the two models by overwriting WSM data with the WECC base case model is also not recommended. The desired solution is one that preserves the detail from both models, and maintains the familiarity and the functionality of both models for the uses to which both planning staff and real-time staff will put them. This is an "integrative" approach to implementing a common model, rather than a "replacement" approach.

The Integrative Method

1 Topological Nodes and Connectivity Nodes

Critical to an integrative approach is the realization that what the planning tools call "buses" are a fundamentally different class of object from what the EMS tools call "buses" or "nodes". The common information model (CIM) recognizes this and refers to the two different objects as "TopologicalNodes" and "ConnectivityNode" respectively.

EMS systems that use the IEC Common Information Model standard 61970 Edition 3 already distinguish Connectivity Nodes from Topological Nodes, and support a containment relationship between them, where any Topological Node must contain one or more Connectivity Nodes; and a Topological Node is a type of “Identified Object” with a permanent non-volatile name and description. Connectivity Nodes may be contained only by zero or one Topological Node. An example of how Topology Nodes and Connectivity Nodes are used can be found in section 4 of the appendix.

Even legacy EMS systems already recognize the distinction between Topological Nodes and Connectivity Nodes, and may include among their network applications a "topology processor" capable of merging all the nodes that are joined by closed zero-impedance devices into a single Topological Node equivalent to a planning "bus". A shortcoming of legacy EMS systems is that they apply arbitrary bus numbers to the topology that they produce, and these bus numbers change since switching devices that are in their non-normal state create new Topological Node arrangements. That shortcoming is overcome by more recent Topology processors that assign a non-volatile name to any Topological Node that is in its normal configuration, and use a specified range of unassigned identifiers for Topological Nodes resulting from abnormal switching states. Vendors of EMS software must, if they have not already done so, implement the ability to specify a non-volatile persistent association between connectivity nodes and those topological nodes represented under normal system conditions.

Vendors of planning tool software must also implement Connectivity Nodes as a separate class of object from “buses”. The technique of flagging zero-impedance branches to represent breakers and switches, and creating bus numbers as Connectivity Nodes (grouping buses together implicitly into Topological Node groupings), does not meet the all desires of integrative modeling as described in section 2. The primary desire which is not met is the use of static topology node identifiers as keys of other elements (such as generators, transformers, etc.).

For this reason, to aid in the transition to these new models, Power flow software vendors are asked to provide a mechanism of maintaining static identifiers for Topological Nodes. In addition some mechanism for designating the difference between a transmission element (line, transformer, or series reactor/capacitor) and a switching devices (breaker, disconnect, fuse, load break disconnect, jumper, etc.) will be necessary. Also we recommend that software vendors provide the ability to view system diagrams using either Connectivity Node detail, or the higher-level Topological Node layout. In addition in the short term the ability to continue defining contingencies using syntax that uses topology node’s static identifiers (such as bus numbers) should be maintained. In the long-term though we highly encourage the syntax is switched to using element labels instead.

2 Building Models With An Integrative Method

The integrative method continues the status quo of having two models maintained, the WECC base case model and the WSM. However, the WECC base case model can be built to include the one-to-many containment relationship of Topological Nodes and Connectivity Nodes. In the immediate term, this allows users of the WECC base case to continue using the syntax that uses topology node identifiers (such as a bus numbers) to refer to elements in the system (such as generators, transformers, etc.). The WECC base case will however be augmented to include the labels used in the WSM model as well thus enabling the engineering community to start using these identifiers themselves or at the very least pass data back to the maintainers of the WSM model using the identifiers which are uses in the WSM model. With these software requirements implemented, the integrative model-reconciliation process would comprise the following actions:

1. Owners of planning data who submit updates to the WECC BCCS will begin to enter Connectivity Nodes, switches, and their configurations into their planning models, using connectivity-node names, switch-names, and node-breaker topology from the WSM. These data will be entered gradually over time, consistent with a realistic schedule to be defined between PEAK and WECC, recognizing the other demands on planning and staff's time, with the most significant system buses prioritized. No changes to the existing bus-branch topology or functionality are intended by simply adding these additional data.

2. WSM data submitters, and WECC BCCS data submitters who submit modeling data for the same physical elements, shall identify one another and collaborate to create business-to-business procedures to maintain consistency between the two models on a go-forward basis. Such procedures must address: adding new planned facilities, updating simple planned configurations with detailed design configurations as work proceeds, reflecting the impact of schedule changes, removing retired facilities, and coordinating corrections to the modeling of existing equipment. The mapping of information between these two systems however should following the element label identifiers used in the WSM model.

3. In any situations where the discrepancies between the real-time model as previously submitted to the WSM and the planning model as previously submitted to the WECC BCCS cannot be resolved by the simple addition of additional Connectivity Nodes and switches to the WECC Base case model, then one or both modes should be changed using the coordinated model-correction process established between the two responsible data-submitters. Changes should be driven by the principle that the model should support the highest-detail representation of the actual real-world equipment required by either of the parties, along with creating spurious models of equipment that does not really exist ("modeling artifacts") that may be required to work-around various software limitations.

The WSM case data comes from a very consistent source but planning cases tended to have consistency problems because they started from various cases. To address this and other issues WECC is implementing the Base Case Coordination System (BCCS). The BCCS will use a single base topology for all planning base cases. In order to alter the base topology for the desired base case files are stored in the data base to change load and generation profiles, and add planned projects to the case. This structure allows data owners to load a single file into the BCCS that will consistently enhance the bus-branch topology at the desired location with a node-breaker representation in every case built afterwards.

For the transition from bus-branch to node-breaker to be effective consistency must be ensured between the WSM and WECC base cases. This will require a common data source for the models and consistent names in both sets of node-breaker models to allow the WSM and base cases to be compared and validated. Names used in the WSM models should be incorporated into the base case node-breaker connectivity models.

Although data owners can build their models by hand, a method of incorporating consistent models is for the data owners to obtain their node-breaker models from their Peak RC representative. The key aspect of this process is that the incorporated models will be compared to the WSM models and any differences will need to be rectified.

3 Maintaining Models With The Integrative Method

The process to maintain the BCCS integrative case consistent with the WSM case can be seen in Figure 4 below. The key aspect of this process is the comparison report. This report would be based on a comparison of the node-breaker data in both cases based on common facility labels. Differences in this data would be relayed back to the TOs, GOs, TPs, and PCs for investigation and corrections. Errors would then need to be corrected in the data base with the identified error (EMS/WSM or BCCS). This process would be ongoing in order to maintain the quality of the models.

Process of Maintaining Cases

[pic]

Figure 4: Process of Maintaining Cases

Adoption of the process shown above (Figure 4) would allow for a consistent data set. The process would also allow both the WSM and the base case models to improve in quality and accuracy because people would get the opportunity to compare the BCCS and WSM models and identify problems and inconsistencies.

The recommendation of using the integrative method approach is a way to allow data owner’s full control of and responsibility for their data. It will also help to eliminate unintended differences between the planning models and the operations model.

Appendix

Node-Breaker Modeling

Currently the majority of off-line planning studies are using bus-branch models to represent power system networks. These models typically represent each substation with a single bus at each nominal voltage level (topological modeling). Without knowledge obtained outside the represented bus-branch model it is not possible to determine the substation breaker configuration and how it operates during contingencies. The lack of breaker information requires that a large number of contingencies must be manually created to replicate bus contingencies and breaker failure contingencies. This manual effort often presents an opportunity for human errors to occur and takes a lot of time to reconfigure buses for study work.

A solution to this is to insert node-breaker (connectivity) models to amend the simplified bus models in the bus-branch configuration. Node-breaker models can provide a fully built out substation representation (i.e. elements such as breakers, switches, branches, shunts, etc. are modeled individually and connected via connectivity nodes). These models provide several advantages over the simplified bus-branch models including but not limited to:

• Providing improved visibility of substation configurations and equipment

• Showing case specific switch and breaker statuses

• Providing enough information for power flow programs to fully automate the creation and processing of contingencies. An example would be to enable automatic inclusion of stuck breaker contingencies.

• Simplifying the modeling and simulation of protection system operations

• Allowing the use of compatible data sets to be used for operational studies and planning studies when representing existing topology

• Assisting in model validation from PMU data and system disturbances

• Allowing for easy and smooth representation of topology changes within substations by changing the status of switching devices (e.g. bus splitting)

Common tower and common corridor outages would continue to need to be inserted manually.

Node-Breaker Element “Names”

Names are invariant identifiers of elements in node-breaker models and are derived in the Peak Reliability EMS for use in WSM cases by splicing together facility attributes that include node names, voltage(s), facility type, facility number, areas, zones and owners. Bus numbers are not used as bus identifiers in EMS and the WSM. Also, WSM cases include bus segments, breakers and switches whereas the WECC planning cases do not include them, yet. The node names, area numbers, and owner numbers that Peak Reliability uses and maintains are usually not the same as those used in WECC planning cases. So while the names in the WSM are derived from EMS facility attributes the same names cannot be derived from attributes in the planning cases because the attributes used are different.

In the BCCS facility attributes in connectivity modeling will be assigned and maintained by the TO/GO/TP for existing and future facilities. This includes descriptive attributes such as bus names and numbers, planning areas, zones and owners. In order to map facilities between BCCS planning cases and WSM cases, the WSM facility labels will be inserted by the TO/GO/TPs as a facility attribute for their facilities in the WECC planning cases.

Power Flow Program Capabilities

Below are some of the basic capabilities needed by the power flow programs commonly used in WECC for node-breaker modeling:

• The system simulation software will need to support this by retaining bus-branch data and linking node-breaker data to it.

• Ability to automatically produce simplified one-line views of bus configurations at substations by a bus voltage level (topological representation).

• Ability to specify a node-breaker or a bus-branch one-line view of the data and solution.

• GUI interface designed for building node-breaker substation representations using drag and drop capabilities to insert bus components like breakers and switches.

• Connectivity processing:

o Ability to determine which breakers are needed to isolate a given element or group of elements under a common protection system.

o Automated contingency analysis that identifies each of the possible element outage scenarios for a given class of contingencies (such as stuck breakers) using the node-breaker information.

• Capability of applying node-breaker representations on a station by station basis.

• Ability to equivalence node-breaker connectivity detail to a bus-branch topological representation for individual station buses.

• Added detail should not significantly increase solution processing time.

• Existing models should continue to appropriately model equipment; the added detail should not negatively affect accuracy of the solution/model.

Some of the major power flow programs already have some of above mentioned capabilities.

Example

The 240kV line “900L” runs from 17S Benalto to 63S Red Deer. The following are typical EMS views of these two substations and the line joining them:

[pic]

A normal power flow Single-Line Diagram (SLD) of these substations and line looks like:

[pic]

An older "GEXM" view (from PSS/E version 26) of bus 155 can be used to reinforce the understanding of Topological Nodes (i.e. planning buses) as a container:

[pic]

When node-breaker data is integrated into the traditional bus-branch data, bus 155 above will look like:

[pic]

The traditional bus configuration still exists. Contingencies can still be defined using “frombus-tobus-ckt” notation, so contingency files that were created manually can still be used. However, we would request that the models be augmented to allow the specification of label identifiers for a branch as well to make the future migration away from the use of these bus identifiers easier. New contingency definitions can be created by examining which breakers must trip to clear a fault and what the clearing times of those breakers are, and that new functionality comes with no loss of existing functionality. Of course, to realize that additional functionality throughout the system, integration of the breaker-node topology into the bus-branch topology must be completed. SRWG should define a realistic schedule over which integration is to be completed, until finally full integration is achieved.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download