Download
1 / 14
140 likes | 347 Views
RATC/ARPA-E Review Meeting. Update on Communication Network Architectures and Topologies: Task 2 Progress. Applied Communication Sciences Contacts: Sami Ayyorgun sayyorgun @appcomsci.com (908) 748-2279 John Sucec js ucec@appcomsci.com (908) 748-2713 May 23, 2013. Prepared for RATC.
E N D
RATC/ARPA-E Review Meeting Update on Communication Network Architectures and Topologies: Task 2 Progress Applied Communication Sciences Contacts: Sami Ayyorgun sayyorgun@appcomsci.com (908) 748-2279 John Sucec jsucec@appcomsci.com (908) 748-2713 May 23, 2013 • Prepared for RATC
Summary of Progress Since February 1 Quarterly Review • Completed Task 2 communication requirements analysis (Task 5.2) • Substation communication design and related performance issues • Both baseline RATC program communication architecuture and future advanced communications reviewed • RATC collaborations • Discussions with TVA to understand typical utility communication network capabilities (March 15, TVA) • Discussions with TAMU to understand RATC algorithm substation data needs (April 4, conference call) • Key conclusion: RATC data needs will comply with utility communication network constraints (at least for its test scenarios) • Next steps • Additionally incorporate details of test plan specification (Task 1.10) in communication analysis • Begin Task 3, identification of communication resource adapation needs
Requirement Analysis Overview • Key questions for communications peformance analysis: • At what periodicity and with what timeliness must substation data be delivered to RATC Analytics? • At what periodicity and with what timeliness can substation data be acquired across utility communication networks?
Backhaul of IED/RTU Data • Utilities employ a mix of TCP/IP-Ethernet and legacy serial access technologies to substation systems • IED/RTU data initially backhauled to SCADA/EMS at Transmission Operator (TOP) CC • SCADA information exchange over private utility WAN may additionally be required for access by RATC algorithms deployed at an ISO CC
Obtain IED Data Flow Event Sequence Diagram • Where possible, baseline RATC program leverages communications performed natively by the utility • Only step 4 represents new communications and this operation is completed over a high-speed CC LAN • Step 1, completed over the utility SCADA WAN, represents the most challenging operation in the communication flow
Overview of Data and Flows Required for RATC Substation Algorithms • RATC Cascade Event Detection and Circuit Breaker Evaluation algorithms demand event records from substation IEDs/RTUs • Data backhauled over utility SCADA/private WANs for access by RATC • RATC Relay Settings Coordination algorithm recommends activation of specific pre-computed relay settings • Commands first reviewed by human operator
Requirements Analysis Background (1 of 2) • Key communication parameters pertinent to the requirements and performance analysis:
Requirements Analysis Background (2 of 2) • Survey of substation DFR event record acquisition revealed a diverse set of available communications capabilities • E.g. distribution of TVA DFR units:
Communications Performance Analysis • Survey-related discussions sought to identify where utility communication capabilities and RATC substation algorithm needs overlapped • While IED/RTU polling intervals vary from substation to substation, RATC algorithms can still be tested and demonstrated for those electrical transmission lines whose endpoints are monitored according to TReqPoll • RATC algorithm deployment and application can, therefore, be incrementally expanded over time according to utility communication capabilities • (where 1 ≤ α≤ 2)
Conclusions • Compliance: The baseline RATC program communication needs will comply with typical utility communication network performance constraints. • Flexibility and Scalability: The deployment of baseline RATC substation algorithms is sufficiently flexible to accommodate varying availability of substation data across utility providers. • Testability: There are electrical transmission lines in typical utility networks where the required substation data is available to support initial proof-of-concept testing of RATC algorithms. • Optional Capabilities: Should there be optional advanced capabilities proposed for RATC that demand enhanced communication network performance there are standard Layer 2/3 mechanisms that can be applied in utility network systems to help protect transport of the data needed by RATC. • Next Steps: The next steps include incorporation of the test plan specification in the communications analysis and identification of communication resource adaptation needs.
Baseline Communication Requirements • Applying communications survey and requirements, RATC communications requirements (both functional and QoS-related performance requirements) have been identified:
Advanced (Future, Optional) Communication Requirements • RATC communication functionality and QoS-related performance needs were simlarly formulated for future (optional) communication capabilities applied for advanced real-time monitoring and control of substation elements:
