1. ODL Overview ODL Design Features Every RATC Component benefits from the same operational data layer interface Data is easy to consume through the use of a common RATC measurement ID Flexible, abstracted, file-based interface couples easily with the broadest range of platforms and applications ODL provides the configuration service of mapping input source data IDs and configuration into RATC measurement IDs Full-featured publish/subscribe APIs available for direct interface to applications written in C#, C++, or Java RATC - ODL Operational Data Layer The ODL Provides • An extensible, common interface to measurements for RATC components • A RATC historian data archive • A library of COMTRADE files • Tools for ODL configuration Operational Data Layer Why is ODL important? • Component Requirements -- RATC is innovative in its integrated use of analytics that require accesses to both classic grid measurement data and data from substation IEDs • THE ODL ASSURES THAT MEASUREMENT DATA IS AVAILABLE “ON TIME” FOR RATC COMPONENT USE • Commercialization Preparation – On-budget, on-schedule integration of new control systems with existing ones is among the critical success factors for new system deployment • THE ODL IS NECESSARY TO CREATE A GENERALIZED ARCHITECTURE THAT CAN BE INTEGRATED WITH EXISTING CONTROL CENTER SYSTEMS • Reduced Project and Product Costs – The ODL avoids duplication of effort among RATC component developers • THE ODL CREATES THE SIMPLIEST, EASIEST TO MAINTAIN OVERALL DATA ACCESS SOLUTION • Adapters to get measurements from control center systems and IEDs • SCADA • State Estimator • Processes to access data from IEDs stored in an event file library GPA Project Tasks • COMTRADE • SDX Document requirements for the RATC operational data layer, or ODL Extend the openHistorian to meet the operational data layer requirements of RATC analytics and make it available through APIs to all RATC components Develop ETL applications for TVA to load operating data into the openHistorian Collaborate with team to meet project objectives, work with TCAT on developing user group, provide training on the openHistorian and its APIs • Historian • Data from all input sources are stored as points represented by ID, Time Stamp, Value and Quality • Enable the Storage Layer to be the nexus for operational data at all sampling rates • Event File Library RATC Data Layer Open Source Framework Common interface for all RATC components Both pub/sub and file-based interface provided • GPA work will take advantage of and extend the existing GPA open source product suite • Many routines are part of GPA’s Grid Solutions framework -- a security tested collection of .NET 4.5 functions • Most RATC project work will be used to enhance and extend GPA’s openHistorian product • High assurance that the APRA-E investment will realize good return through the strong GPA user community Unique measurement point IDs (GUID) Mapping of multiple alternate names Configuration automation tools provided as part of the process to connect to data inputs • RATC requires interfaces to multiple existing systems within the deploying entity, e.g. model management, SCADA and scheduling systems. • The ODL manages the interfaces to the measurement-providing systems (green boxes)