1 / 15

RATC Data and Communication Layers

RATC Data and Communication Layers. Alex Sprintson. Outline. Task 5.2 Identification of Communication Specifications and Performance Requirements of the (Sub)System and Applications involved in the overall RATC Solution

caraf
Télécharger la présentation

RATC Data and Communication Layers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related