| Clarifications from the Pre-Bid Conference (1) | |
| If your company’s self-evaluation for a particular module is partially MF and partially CE or UD, please provide detail on a percentage breakdown, and this will be taken into account in the evaluation. | |
| Clarifications from the Pre-Bid Conference (2) | |
| Costs shown in table 4 should reflect the cost to fully develop each specified function. | |
| Clarifications from the Pre-Bid Conference (3) | |
This is a restatement of evaluation methodology:
- F values will be the total of responses from Table 2 weighted with values in Table 6
- T values will be the total weeks in Table 3 weighted with values in Table 7
- C values will be the total costs shown in Table 3 weighted using values from Table 7
| |
| Clarifications from the Pre-Bid Conference (4) | |
| F & D values will be added together without additional weighting. | |
| Clarifications from the Pre-Bid Conference (5) | |
| To calculate V, we need to know how many years your company has been in business, and the number of applicable platforms you have deployed. | |
| Page 4 under ASCII Data Format: The definition includes “other power flow program data that can be read by a text editor” What other data does WECC envision is included here? | |
| The BCCS initially requires support of the following formats: PSLF (power flow, dynamic, and short circuit formats), PSS/E (power flow, dynamic, and short circuit formats), BCC format (as defined in section 2.10), and CIM/XML format. However, in the future the BCCS should be extensible enough to support other formats as desired. | |
| Page 9 – There is mention of “exportable in user-defined lists”. How many lists are to be covered in the BCCS? Can WECC define the file formats that need to be exportable? How does WECC envision the interface between the TEPPC database and the BCCS? | |
| A BCCS user should have the ability to query the data tables within the BCCS and generate user-defined text, csv, or columnar reports. | |
| Page 11 – The diagram on top of this page indicates that the transfer between the BCCS and WSM will be via a bus-branch representation. In other parts of the RFP, breaker-node model support is discussed. How does WECC envision the WSM-BCCS transfer working? | |
| As it exists today, the WSM has a topology processor built in. This will enable us to use the existing WSM to export data in bus-branch representation. However, in the future we envision the possibility of the planning model converting over to a node-breaker representation, so we want the BCCS to have the ability to store data in both formats. | |
| Page 11 – The diagram on the bottom of the page shows “Future Data Exchange” with other systems. How does WECC envision that this data exchange will take place? | |
| Data coming from other sources will need to have common identifier tags (e.g. for linking PI historian data with base case data) that the BCCS can use to associate external data with base case data contained in the BCCS. | |
| Page 12 – Section 1.5 – last sentence – Please describe what is meant by “The full BCCS implementation will take place in stages and in coordination with the further development of the WSM”. How will the WSM be developed in the future? | |
| The topology processor of the WSM needs to be updated to map the most current WECC planning model with the operating model found within the WSM. Depending on the timing of the BCCS implementation and the progress of this mapping, the BCCS may be initially populated with an existing WECC planning base case as a starting point. Other changes to the WSM product can't be determined at this point. | |
| Section 2.1.1 – What are “data category” tables? | |
| Data category tables refer to the collection of parameters for individual elements of the power system. For example, data category tables include the bus table, generator table, transformer table, etc. | |
| Section 2.1.29, 2.1.30 – Which users would perform these user-written SQL queries? Would these queries be selects only, or would these users need to be able to change data through DML operations? | |
| All users should be able to perform user-written SQL queries. SQL query should only be used to obtain and not change data. | |
| Section 2.2.5 – How does WECC envision the database will be populated from ASCII data formats? | |
| ASCII data formats include RAW and EPC formats. Execution of BCC change control files (section 2.10) would also be a way to populate portions of the database. The BCCS should also be able to read delimited files (e.g. CSV format) and perform user-definable data queries (section 1.4). | |
| Section 2.2.8 – Can WECC define the other user-definable fields? | |
| The BCCS should be extensible. In referring to section 2.2.8, "user-definable fields" are labels and equipment-specific information. | |
| Section 2.2.11 – This item is missing the end of the second sentence. | |
| The end of the statement should read, "It should be able to read in a base case and populate the database within approximately one minute." | |
| Section 2.2.17 – Please describe how WECC envisions the planning data storage coordinating with the WSM. | |
| The BCCS will be able to accept and store model data from the WSM. It is not expected that the BCCS will contain a topology processor at this time. | |
| Section 2.2.19 – Please describe the spatial analysis and data management functionality? Will WECC consider other GIS solutions? | |
| Maintain location coordinates for all equipment-related data. Report equipment on maps using a standardized legend and provide layer information for input to GIS systems. Solutions compatible with ArcGIS are acceptable. | |
| Section 2.2.20 – How does WECC envision this functionality working? What does scalable mean? Are there defined API’s for each of these enterprise applications? | |
| The BCCS should be flexible enough to accommodate the addition of relational database tables. | |
| Section 2.3.1 – What is the industry standard file format for “Project” files? | |
| The vendor should define the format for the project files. | |
| Section 2.3.3 – Are there existing defined rules for estimating data that is incorrect or missing? | |
| The BCCS shall not automatically replace or insert missing data. See requirement 2.5.4 for data quality checking. | |
| Section 2.4.3 – Can two or more users at the TSO level veto an area coordinator's decision? | |
| This is not applicable. The BCCS does not enforce policies or practices. | |
| Section 2.5.2 – Can you please describe what is meant by “selectively” flagging differences between cases. | |
| The user should be able to apply filters to the comparison operation. | |
| Section 2.8.4 – Please describe the other messaging channels. | |
| The alert will occur through the BCCS user interface. | |
| Section 2.9.3 – Can you please explain the DC tie parameters for generators? | |
| DC ties are sometimes represented as generators in the power flow. There are no additional parameters needed to model DC ties through the generator model. | |
| Section 3.4 – How does WECC envision the development of other use cases? | |
| The vendor should develop methods to test each function. | |
| Section 3.4.2 – Please describe what is meant by demonstrate multiple-vendor platform capability for case representation and exchange. | |
| The vendor should demonstrate functionality by exporting the data in both PSLF and PSS/E formats and comparing the resultant cases for similarity. | |
| Section 3.4.9 – How does WECC envision dispatch patterns being validated? | |
| Create a use case to compare data entered and data that is actually stored in the BCCS. | |
| Section 4.1 – Please describe the BCCS requirements as they relate to mobile devices? What platforms are to be supported? What functionality is to be supported? | |
| Mobile device support capability is not required. However, any supported functionality should be stated by the vendor. | |
| Section 5.2 – This section calls for an independent agency to conduct vulnerability testing. Is this testing cost to be included in our response to the RFP? | | |
| Section 6.1 – Please provide the applicable WECC and NERC requirement related to data retention. | |
| The BCCS shall provide a minimum of five years of data retention. The DBA shall have the ability to expunge data. | |
| Section 9.1 and 9.2 – Can WECC provide the anticipated training requirements? Number of courses, location of training, and number of students. Will online training be acceptable? | |
| Vendors shall provide anticipated start-up training requirements and costs based on a "per student/group" or "per session" basis and shall be added to the cost tables in Appendix A. For cost estimate purposes, the vendor should assume training will be hosted at the WECC offices in Salt Lake City. Online training is acceptable. | |
| Appendix B – What are the numeric values for the development milestone weights and the evaluation weights? | |
| Percentages for the weights will be applied consistently between table 6 and 7. | |
| Appendix A – Table 4 – The response for completion time assumes requirements are completed in series. How does WECC intend to account for interdependencies and overlap between milestones and requirements? | |
| Vendors have the flexibility in reporting anticipated project timing, but shall provide as much explanation as possible when submitting proposals to table 3. Table 4 shall be used as a worksheet for populating table 3. | |
| Section 2.1.17 - Can WECC please provide additional information on their desire here and explain “separate workspace” and their vision of this need. | |
| Users must have the ability to work with and modify data without it affecting the production database. | |
| Section 2.4.10 - Will WECC provide the WECC Data Preparation Manual in order to facilitate understanding of this requirement? | |
| The WECC Data Preparation Manual has been placed in the "BCCS Document Library" section above. | |
| Section 2.6.6 - Can WECC elaborate on the inclusion of voltage and frequency load shed relays in this functional specification section? How is the validation case to be used? | |
| All data in the dynamics database shall be associated with the power flow model. | |
| Section 2.9 (Database Contents) - What economic data is expected here? Heat rate curves? Dispatch data after Economic dispatch performed? Other? | |
| The database shall have the ability to accommodate generator data fields for economic information including those contained in PSLF and PSS/E generator tables. | |
| Page A-2, item 3.2 - User Uploads references Steps 1 through 5 for Functional Requirements. Should this be "Steps 1 through 4"? Or, the description for Step 5 may be missing on page 29 under section 3.2 User Uploads Planning Data. Please clarify. | |
| The number 5 should be omitted from the diagram. | |
| RFP - GENERAL - What type of unit commitment approach is desired by WECC for the WECC BCCS purpose? | |
| Generator dispatch is entered on a case-by-case basis by the user. | |
| RFP 1.2 - Are multiple (greater than two) terminal DC models required? | |
| Yes, the BCCS shall be able to support DC networks. | |
| RFP 1.3 (bullet 2) – Could WECC distribute descriptions or examples of WECC documents for “Loads and Resource Summary Sheets”, “Significant System Changes List”, the PSS Tabulation, and the Series Compensation Levels of Major Transmission? | |
| Base Case data and information can only be distributed to WECC members or those who have signed an NDA. If you wish to receive this data, please contact Branden Sudduth at branden@wecc.biz. | |
| RFP 2.1.16 – In what form are RAS and relay models to be exported and imported to PSSE and PSLF files? | |
| Relay models should be submitted in standard dynamic data file format. RAS and other relays that must be implemented using run-time programming are not part of the initial BCCS focus. | |
| RFP 2.1.18 - What are the modeling requirements for JOU’s (Joint Owned Units)? Please describe how multiple inputs are provided and coordinated. | |
| Each owner has control over its portion of the generator. | |
| RFP 2.1.21 - Is there a model for “path users” which WECC will supply? | |
| Footnote 6 was intended to refer to area-to-area interchanges. Notice would be provided when a user pushes a value to the database. Values could be changed within a user's workspace without notification of other parties. | |
| RFP 2.2.15 - Can WECC provide the detailed specifications for the required PSSE and PSLF versions to the successful vendor? | |
| Selected vendor shall be provided this data. | |
| RFP 2.2.7 – In partial exports, are there specific requirements regarding tie points representation between filtered and exported data? | |
| The user should have the option of including or excluding tie points. | |
| RFP 2.2.7 – What is the meaning of “modeling level” in this context? | |
| Modeling level refers to the amount of loading. | |
| Ref 2.8.4 – Please list the applicable NERC reliability standards from your perspective | |
| The applicable NERC standards include, but are not limited to, MOD-010 and MOD-012. | |
| RFP 2.9.8 – How will these solution parameters be exported by PSSE & PSLF for import? | |
| ASCII data format as part of the program raw data file. If not part of the raw data file, it must be entered manually. | |
| RFP 4.10 – Is the FACTS device model represented by PSSE v31 representative of what is desired? | |
| The BCCS will need to be updated as model improvement occurs. The BCCS shall support the current PSLF and PSS/E data structures. | |
| When is the project likely to start? | |
| Due to the WECC review and approval process, WECC is anticipating the following start dates: Notification of Award - March 2011, Kickoff - April 2011 | |
| While it is not mentioned, we would like to suggest that the sequence network data should be included in the database, as this is required for unbalanced fault simulations included in the latest NERC TPL planning criteria. We would like to have comments from WECC on this. | |
| Current program data fields include sequence data. It is expected that the BCCS will have this functionality. | |
| The BCCS needs to handle extensively data (importing and exporting) in PSS/E and PSLF formats. When the contract is awarded to a vendor, will WECC guarantee that Siemens PTI and GE will issue PSS/E and PSLF licenses to the vendor for the development and maintenance of BCCS? | |
| No. It is expected that the vendor will acquire the PLSF and PSS/E programs independently. | |
| Our intention is to provide support for one specific version of PSS/E and PSLF data in the base bid of BCCS. We would like to have comments from WECC on this. | |
| This is acceptable. However, ongoing maintenance costs of the BCCS should take into consideration effort required to keep the BCCS up-to-date with future revisions of PSLF and PSS/E. | |
| What specific version of CIM should be supported in BCCS? | |
| The most current version, including CIM for Planning and CIM for Dynamics. | |
| The RFP requires the support of many data formats as input (in some cases output as well), for example, PSS/E Raw, PSS/E IDV, PSS/E PSEB, PSS/E PSAS, PSLF Raw, PSLF EPC, PSLF Post-transient switch-deck program, PG&E macro processor, CIM/XML, BCC specifications (to be developed in this project), Excel, Access, SQL queries, Python, ArcGIS, and so on. Some of these might be version dependent, poorly defined, or proprietary. Supporting of all these formats may be very challenging. Is it possible that WECC can limit these to a few popular and widely used formats? | |
| The BCCS initially requires support of the following formats: PSLF (power flow, dynamic, and short circuit formats), PSS/E (power flow, dynamic, and short circuit formats), BCC format (as defined in section 2.10), and CIM/XML format. However, in the future the BCCS should be extensible enough to support other formats as desired. | |
| Integration with WSM data is a desired feature in the RFP. It is recognized that operational models/data maintained in EMS and planning models/data are very different, for example, in terms of modeling concept/methods, modeling details, and data/information available. For this reason, integration with WSM data offers extremely high risk for success of this project. Therefore, it is assumed that this capability might be developed in the future. We would like comments from WECC on this. | |
| Yes, this is a desired future capability. The WSM-BCCS presentation refers to mapping. This is not intended to be a separate off-line process, but would be a built-in conversion definition in the operations database outside of the BCCS. | |
| Some vendor specific terminologies are used in RFP, for example, bface and iface tables in PSLF. We need clarifications on these. | |
| The iface and bface tables in PSLF are informational tables which contain the path number, name, rating information, and individual branches which make up those paths. More information will be provided to the successful bidder. | |
| Regarding functions and keywords described in Section 2.10 - Basecase Change Control Methodology, are you looking for a new application with functions and command language exactly as described, or would an equivalent system suffice? | |
|
We are not looking for an exact match. The list of command keywords and required capabilities included in Section 2.10 does represent a starting point, or minimum functionality. We expect that other functionality not expressly described in the RFP will be needed for a workable implementation of the methodology described. For example, functions related to dynamic data will need expansion so that project files that add generating facilities can update both steady state and dynamic model information. As summarized in Mr. Graham’s presentation, four primary functions must be supported:
Project definition (operations needed to add facilities while ensuring network solvability)
Maintenance (add/modify/delete/scaling)
Validation (data checks and reporting)
Scenario definitions (sub-areas, transmission paths, and area-interchange operations)
| To support these functions, the application will need to handle conditional statements, stored variables and logical arguments, input/output operations, and have some programming capability, as described in 2.10. Functions will need expansion beyond the minimum described, and addition and adjustment of command lines and keywords, or substitution with equivalent features, should be acceptable. | | |