RATC Data and Communication Layers

1. RATC Data and Communication Layers Alex Sprintson

2. Outline • Task 5.2 Identification of Communication Specifications and Performance Requirements of the (Sub)System and Applications involved in the overall RATC Solution • Deliverable 5.2.1 - report on communication system performance criteria and QoS requirements for different parts of RATC design in all of the project stages: development, demonstration, and implementation (due June 28, 2013) • Discussion of Integration and Data Layer options

3. Outline • Part 1 - Dr. A. Sprintson • Overview of data and communication layers • Options for RATC data layer • Part 2 – Dr. John Sucec • Communication specification and performance requirements

4. Sprintson’s team • Q1 2013: • Contributed to RATC architecture document • Contributed to Data Flow specifications (including TVA visit) • Contributed to Communication Specification • Q2 2013: • Thorough evaluation of Data Layer options • Create working demo for one or two RATC modules

5. RATC Data and CommunicationsLayers Overview • Data Layer • Relies on the communication layer for data gathering and delivery • Affects communication layer requirements • Tightly coupled with RATC architecture • Communication layer • Has a critical role in providing QoS • Need to be robust to failures • Tightly coupled to utility infrastructure

6. RATC Data Layer

7. Data Layer Options • Historian (OsiSoft PI-Historian and GPA OpenHistorian) • WSDL/SOAP-based Web Services • Apache Camel Framework

8. 8 Historian • Historian software keeps records and provide APIs to access required files/data • Various products exist like OpenHistorian, OsiSoftPIHistorian, etc. • Historian database system used which is customized towards real-time process data • Harder to customize • According to discussions with component owners, historians are not required • RATC modules mostly use processed data from packages • Components do not require the degree of granularity provided by Historians

9. SOAP-based Web service architecture for RATC

10. Apache Camel Framework • Open source integration framework based on Enterprise Integration Patterns • Enables to define a variety of routing and mediation rules • Various components to implement non vendor specific solutions • Example context to define a route- • CamelContext context = new DefaultCamelContext(); • camelContext.addComponent("activemq", activeMQComponent("vm://localhost?broker.persistent=false"));

11. Apache Camel architecture for RATC

12. Comparison of options

13. Data Layer API using Camel • Camel provides support to clients by defining them as endpoints • It would refer to a software entity that is contactable at that address • In a Camel-based application, we would create Camel wrappers around the endpoints and connect these endpoints with routes • Camel provides libraries like ActiveMQ-CPP, to interface with RATC components in C++.

14. Implementing Test Cases with Camel

15. Conclusion • Support the architecture effort to document Test Plans and Test Cases for each component and combined high-level scenarios • We will continue evaluation of these three approaches (Historian ,WSDL/SOAP based web services and Apache Camel framework) • With a focus on scalability • Will focus on Apache Camel for internal implementation • Implement demonstration based on selected test cases • Develop API for different modules.