Business Needs 1.4.20 - Improve comparison of dynamic study case data with steady-state case data. | What information is going to be compared, by who, and how will that then turn into notification? | The purpose of this requirement is to compare generator power flow data modeling with machine dynamic data modeling. First and foremost, the BCCS should identify generating units represented in the power flow without a corresponding dynamic model and notify the individual entering the data that a dynamic model must be submitted. Next, the BCCS should flag any discrepancies between the power flow and dynamic models, such as bus name, generator id, pmax, etc. and notify the individual entering the data. |
Business Needs 1.4.16 - Provide greater flexibility in base case production. | Please clarify - what/which point of reference is considered; greater to what? | The base case preparation is currently being performed manually, thus we are only able to compile a limited number of cases per year with very specific case conditions being represented. Using stored data (loads, generation, system topology, etc.) in a data base and an automated process would allow an individual the flexibility to create various base case scenarios without having to coordinate with various entities to model various loads, interchanges, and generation dispatch. Automating the base case preparation will not only allow more flexibility to create a scenario, it will also reduce the amount of time to prepare a base case.
Any data corrections or updates that are applicable to multiple cases must be reapplied. Since each case contains multiple data files, version control and error correction can be difficult. Please refer to the WECC Case Compilation Schedule for the current annual case production. The Base Case Process Issues list gives more examples of our current limitations. |
System Functional Requirements 2.3.9 - Compare total load by bus to circumvent load-ID problems. | Please clarify "load-ID problems" that are being referred to. | Load buses close to base case area boundaries can contain two loads (with different id's) submitted by two separate entities representing the same load center. This can result in double counting of loads. Also, loads transferred to new buses can sometimes remain at their old buses, also resulting in double counting of loads. Load forecasts should be compared to bus load totals to ensure that loads are not being double counted. |
System Functional Requirements 2.3.10 - Accommodate long-term forecasts (10 years and beyond) vs. Business Needs 1.4.17 - Develop (potentially) longer-range cases (in the 10-15 year time frame) as a result of improved data management. | The two requirements are similar. Please clarify their scopes and state differences. | The two items both illustrate the need for the BCCS to be able to accommodate long-term planning efforts. The ability to accommodate long-term forecasts is a subset of the ability to develop longer-range cases. |
System Functional Requirements 2.1.4 - Apply profiles for year-over-year scaling of network values to achieve simulated conditions of the desired study case. | Does year-over-year scaling apply to anything other than load and generation? | System representation, including generation dispatch, load forecast, and system topology for short and long term base case development should be considered. |
System Functional Requirements 2.1.7 - Store frequently used profiles and queues as pre-defined starting points for planning case assembly. | | "Queues" is referring to the ability of the BCCS to store profiles based on in-service/out-of-service dates. If the user wishes to compile a future year planning base case, the BCCS should include all projects that will be in-service at the time frame being modeled and the BCCS should not include projects that will not be in-service during the time frame being modeled. The responder should describe the detail available for modeling projects and phases. |
System Functional Requirements 2.1.8 - Designate criteria for construction of a target planning case, per the WECC case compilation schedule.
| Please elaborate - what is the system supposed to be doing here to help with tracking progress? | As part of WECC base case compilation, the WECC System Review Work Group determines specific years and operating conditions that they would like to represent in the cases that WECC compiles. The BCCS should be able to accept specific criteria specified by the user to construct a base case. For example, the user should be able to specify a year and load condition to create a 2015 summer peak load case. |
System Functional Requirements 2.3.3 - Compare data submitted by different entities, flag differences, and prompt appropriate action through alerts and notifications. | Please explain the type of differences expected in data submitted by different entities. | Any elements connected to two different entities, such as transmission tie lines, need to be consistent between the two data submittals. For example, if a transmission line connects area A to area B and area A is submitting the line in-service for a given time frame and area B is submitting it out-of-service, the BCCS should notify both entities of the discrepancy. Other potential differences could be interchange scheduling, transmission tie line or transformer tie impedances and ratings, and status of line-connected shunt reactive devices on tie lines. |
System Functional Requirements 2.3.4 - Process data submittals to check and validate bus numbering. | What are the rules for valid bus numbering? | Each base case area is assigned a bus number range which they are permitted to use for case assembly. If a bus number is used which is outside of an area's allowable range, the BCCS should notify the individual entering the data of the error. |
| It appears from the wording of the RFI that the model shown in the figures on pages 14, 15, and 16 is a bus-branch model of the type represented by PSSE and/or PSLF files, as opposed to a full nodal model including switching devices and all of the detailed connectivity nodes in the system. Please confirm this assumption. | This is correct. The BCCS model environment is a bus-branch based model such as those found in power flow programs like PSLF or PSS/E. The figure on page 16 of the RFI illustrates our desire for the BCCS to be compatible with the Westwide System Model (which uses a breaker-node based model) in the future. Although the conversion and mapping from a breaker-node model to a bus-branch model is beyond the scope of this RFI, we would like to make potential vendors aware that it is a long-term goal of the BCCS. |
| In the RFI both member companies and area coordinators are discussed. In terms of the desired BCCS, at what granularity do you intend network data to be submitted: member company, area coordinator, or both? If it is both, how do you intend to assign responsibilities and privileges? | Area coordinators are a subset of member company users. Area coordinators are responsible for compiling data for one or more member systems within a defined geographical area, therefore they are ultimately responsible for the network data in their respective base case area(s). Currently, there are 14 area coordinators who submit network data, but the BCCS should be able to support a larger number if needed. If possible, the BCCS should have the ability to accept data from any member company, but that data would need to be validated by the area coordinator before it can be incorporated into the BCCS network model. Member systems should be notified by the BCCS if either the area coordinator did not accept their data or if the area coordinator made any modifications to their data. |
Business Needs 1.4 - Short-term business needs and Long-term business needs. | You identify both short-term and long-term business needs. In your phased approach, do you envision a specific order of development: i.e. meeting short-term needs in an earlier phase, followed by long-term needs in later phases? | Yes, the short-term business needs (and as many of the long-term business needs that can be incorporated) will be included in the first phase and the BCCS should be able to address most, if not all, of these needs from the start. Long-term needs can be addressed in later phases as technology advances and developmental needs are better understood. |
System Functional Requirements 2.4 - Generate operational or validation base cases from either an EMS data file or State Estimator output data to represent a known system event or disturbance. | What is the format of this exported file? If it is vendor specific, what format is the data? | The format of the exported file from the Westwide System Model is currently PSLF and PSS/E. The BCCS should also be able to import CIM-based data (see section 5.3). |
| Does the RFI response need to be in "hard paper copy" or are CDs ok? | CDs or other electronic formats (e.g. e-mail files) are preferrable. |
Documentation 8.3 - Automated Interface Documentation | Please describe the intent of this interface. Is it how the HMI "looks and feels" or is it how "automated data flow" from the field is represented and manipulated? | The interface documentation should describe, in detail, how users may install and/or utilize an API to the BCCS. If the API is implemented using XML, then the schema shall be provided to the users so that they may implement their own XML processor independent of any specific vendor solution. |
Hardware and Software Standards Section 5.3 - WECC anticipates that the full models and incremental files produced for exchange must be CIM/XML RDF files formatted in accordance with the IEC TC57 CIM standards. | The upload and download use cases described in Section 3.2-3.3 require the planning data to be submitted or exported in PSS/E or PSLF flat files. What is a use case for exchanging model in CIM/XML? | In the short-term, we anticipate that the BCCS will primarily import and export data in PSLF and PSS/E formats until the program vendors incorporate CIM compatibility into their respective programs. As the CIM is further developed, we anticipate that it can have the potential to become a primary format for uploading and downloading data. We also see the CIM as an important bridge between the Westwide System Model environment and the BCCS. |
| What is a typical use case for model maintenance? Does WECC expect each member utility to maintain the portion of the planning model withing their service territories using the centralized single-entry modeling solution? | This is true in a sense. Area coordinators, who are appointed representatives from member utilities, are responsible for the maintenance of system data for one or more member utilities within a defined geographical area. If possible, the BCCS should have the ability to accept data from any member company, but that data would need to be validated by the area coordinator before it can be incorporated into the BCCS network model. Member systems should be notified by the BCCS if either the area coordinator did not accept their data or if the area coordinator made any modifications to their data. |
| Is the intent of the BCCS to allow utilities web access to Data Engineering tools and other applications on a WECC server? | The primary intent of the BCCS is to provide a web-based data management system for handling base case data submitted and used by utilites and WECC staff. Although it should be able to perform simple data checking functions (See section 2), it is not intended to be a medium for accessing any other engineering applications or tools (e.g. PSLF or PSS/E). |