WISP RFI for Applications response summary

1. WISP RFI for Applications response summary • 11 respondents • ABB • Areva • Black & Veatch • Cooper Power Systems • Electric Power Group (EPG) • Harris Corporation • InStep • OSISoft & SISCO • SAIC • Siemens • Space-Time Insight

2. What and Where • Documents: • Individual responses • Application RFI response data • Application RFI response summary • Contacts: • WISP Project Manager for Applications • Scott Woodbury, swoodbury@bridgeenergygroup.com • WISP Technical Architect • Dan Brancaccio, dbrancaccio@bridgeenergygroup.com • WECC Lead Applications Architect • Kirk Stewart, kstewart@wecc.biz • Detailed responses in WISP SharePoint: • http://www.wecc.biz/awareness/WISP/Program%20Folders/Program%20Management/Vendor%20Selection/Applications/RFI/

3. Functional Scope of the Applications RFI • Real-time data display for wide area visualization • Frequency and frequency rate of change • RMS voltage • RMS current (line) • Phase angle • Positive sequence voltage • Positive sequence current • Calculation and real-time display for wide area visualization • Path flow • Reactive capacity/reserves • Voltage stability • Oscillation energy • Mode meter • Percent damping • Monitor real-time PMU and calculated data for alarms • Frequency • RMS voltage • RMS current • Phase angle • Path flow • Reactive capacity/reserves • Voltage stability • Oscillation energy • Mode meter • Percent damping • Display options of all PMU and calculated values • X/Y 2-dimensional • Polar chart of phase angle • X/Y/Z 3-dimensional • State values of alarms • Grid text in rows and columns • Alarm management • Set warning and alarm thresholds or limits • Playback and archive of alarm • Set alarm prioritization / levels • Capture of events based on alarms • Visualization of alarm status in real-time • Power system performance and post event analysis • Post event analysis • Power system performance baseline • Power system performance analysis • System wide model validation • Generation model validation • High voltage DC intertie • Load model validation • System model verification • Export of data in common formats

4. Overall Response Statistics

5. Review Objectives • Understand the functionality of the synchrophasor applications available on the market • Determine the maturity of the synchrophasor application space • Understand the level of engineering and testing necessary to meet WISP business requirements • Collect info on the functional boundaries of the synchrophasor applications and determine the optimal suite/mix of applications • Collect info to establish the optimal architecture for the integration (data, messaging, etc.) of the synchrophasor applications • Collect information needed to plan and execute the next steps of the vendor qualification and selection process • Identify vendor’s application architecture to support continued planning of WECC IT infrastructure • Review vendor approaches to meeting application availability, security, and interoperability requirements

6. Review Findings • The application space for synchrophasor applications is maturing quickly and solutions exist that address the majority of the WISP requirements • Strong feasibility of finding a synchrophasor based situational awareness / visualization application that meets the requirements of the WISP program • Five (5) of nine (9) responses answered Y to over 95% of the questions • Most applications are not fully SOA compliant • Refinement of the technical architecture will impact the suite of applications to be selected in the RFP process • Refinement of the data architecture will impact the integration requirements • Need vendor meetings for further discovery • Finalize the technical architecture and integration approach • Determine the optimal suite of applications • Complete the Statement of Work (SOW) for the Request for Proposal (RFP)

7. Notes on Questions • Question B61: Does the application have functionality to run RMA to locate historical occurrences of patterns? • Only two (2) respondents answered yes to this question (OSISoft and InStep) • The importance of this functionality should be evaluated for the RFP • Question [C4]: Does the application have an API designed to meet the NASPI to Phasor Gateway specification? • Four (4) of the respondents had partial responses to this question, but all of them said further information on the design is required by NASPI before it can be included in their commercial offering • Siemens appears to be more focused on the NASPI phasor gateway.

8. Notes on Questions • Question [C11]: Is the application designed to handle redundant data streams of IEEE C37.118-2005 streaming data? • Of the nine (9) respondents five (5) responded yes to this question • Question [C12]: Is the application designed to have availability of 99.999%? • Of the nine (9) respondents five (5) responded yes to this question • The requirements around question C11 and C12 regarding system redundancy and availability should be investigated further for the RFP • This response is also dependent on the hardware and operating system used to support the application

9. Next Steps • Schedule vendor demonstrations / meetings • Conduct PDC and Apps vendor review meetings together • Demo of product capabilities, architecture and integration • Interested members of TAC sub-groups may participate • Vendors to be invited to these meetings • AREVA, EPG, Siemens SEL and Space-Time-Insight • Develop the Scope of Work for the RFP • Draft the Scope of Work • Incorporate input from the Bus. Req. Spec. • Review the Scope of Work with the TAC Applications Sub-Group • Submit Scope of Work for TAC review • Add SOW to the RFP and send to Vendors