1 / 40

Controls Middleware (CMW) Presentation to the Controls Board

Controls Middleware (CMW) Presentation to the Controls Board. The Middleware Team October 31, 2000. From CB Mandate:. To promote a common approach in controls activities at CERN To recommend to the Technical Director standard solutions for controls at CERN

farren
Download Presentation

Controls Middleware (CMW) Presentation to the Controls Board

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. Controls Middleware(CMW)Presentation to the Controls Board The Middleware Team October 31, 2000

  2. From CB Mandate: • To promote a common approach in controls activities at CERN • To recommend to the Technical Director standard solutions for controls at CERN • To ensure regular communications between the controls teams at CERN • To promote collaborations in controls projects at CERN • Observe the trends in controls at CERN • Set up working groups to prepare general recommendations in controls • Create and monitor join projects in domains of common interest

  3. What is the interest of Controls Board in the CMW Project ? • Presentation and the state of the project (and possibly a demo) • Results of investigations of middleware technologies • Could it cover other middleware needs at CERN?

  4. Outline • Presentation of the CMW project • Background and Strategy • Architecture • Solutions • What is available • Can CMW be applied elsewhere at CERN?

  5. Outline • Presentation of the CMW project • Background and Strategy • Architecture • Solutions • What is available • Can CMW be applied elsewhere at CERN?

  6. The PS/SL Middleware Project • Mandate • Launched in early 1999 as PS/SL collaboration to provide communication infrastructure for existing accelerators • Members • PS/CO: Steen Jensen, Alessandro Risso, Nikolai Trofimov • SL/CO: Vito Baggiolini, Francois Chevrier, Francesco Calderini, Kris Kostro, Marc Vanden Eynden • Recent collaboration with ST suggested by LHC-CP

  7. CMW Requirements • High-level requirements and constrains • Allow inter-object communication • Accelerator device model (named devices accessed by properties) • Support for Java • Publish/subscribe paradigm • Integration of industrial devices • Ultimately replace existing PS and SL communication • Rely on available standards • Detailed requirements published in August 1999 • www.cern.ch/controls-middleware

  8. CMW Strategy • Use standards when available • Use commercial software • Apply an open public design process

  9. CMW Project is a Public Process • Public seminar in March 1999 on technology • User Requirements Document published in August 1999 • Whitepaper proposing architecture and technology in January 2000 • Various small public presentations during 2000 • www.cern.ch/controls-middleware contains documentation, papers, minutes

  10. Project Overview • March 1999 Workshop on MW technologies • August 1999 Requirements from PS/SL control & equipment groups published • Autumn 1999 Selection of technology • January 2000 Technical choices published in the “Whitepaper” • Spring 2000 Elaboration of Architecture and APIs • Summer 2000 Prototype developed • End 2000 in operation

  11. Outline • Presentation of the CMW project • Background and Strategy • Architecture • Solutions • What is available • Can CMW be applied elsewhere at CERN?

  12. Design principles • Technology independent • One stable public interface • Use standards • Use commercial software

  13. User written CMW Existing or off-shelf Public CMW API Private CMW API’s Standard API’s Modular API layering User software or API (PS, PS Timing, SPS2001, CESAR, Alarms) CMW integration layer Device/property model, get/set, pub/sub, complex data CORBA specific or MOM specific concrete implementations of get/set, pub/sub, complex data Commercial MW product (2 CORBA products, JMS product)

  14. Device/Property Model • Control system consists of named devices (position monitor, beam line) • Devices are composed of properties (position, current) • Properties can be composed of elements of simple type(int, float, string,… and arrays) • Operations on properties set, get, subscribe, unsubscribe • Devices organized into device classes • This model is similar to Java Beans

  15. Conceptual model Programming model Device name : String get(property): Data set(property, Data) monitorOn(prop, Listener) monitorOff(property) Data add(entry: DataEntry) . . Device and Data model Device Class Device Property 1 0..n name : String name : String DataEntry 0..n Typed method to insert and extract values

  16. User written Middleware Controls Programs Existing or off-shelf Unix Workstations, Linux, Windows Middleware Client API Middleware Server Framework Device Adapter Physical Device General Communication Model Data structured into named properties Get/Set Publish LynxOS Front-Ends

  17. Outline • Presentation of the CMW project • Background and Strategy • Architecture • Solutions • What is available • Can CMW be applied elsewhere at CERN?

  18. OO Communication • OO RPC • CORBA • Java RMI • DCOM • SOAP (XML-based) • OO MOM • Java JMS

  19. CORBA for Set/Get “Object-Oriented RPC” Available on multiple platforms & languages MoM for Publish/Subscribe Support for the Java Message Service (JMS) API Publication of data to a “topic” MoM CORBA Chosen Technology

  20. Why both CORBA and MOM ?“le meilleur de deux mondes” • CORBA is the only fully interoperable MW • Any language • Any system • Many products BUT • MOM scales better • MOM is excellent for loosely coupled systems • Producer only needs to know the subject • Consumer only needs to know that a subject exists

  21. Evaluated Products • CORBA • HARDPack (Lockheed Martin/USA) • omniORB2 (AT&T/UK) • ORBexpress (OIS/USA) • ORBacus (OOC/USA) • MoM • IBUS (SoftWired/CH) • SmartSockets (Talarian/USA) • SonicMQ (Progress Software/USA)

  22. CORBA evaluation • Interoperability • Java/C++, Linux/LynxOS, Naming Service • Performance • 2-3 ms for Java to Java call • 0.078 ms have been reported for a product • 168K footprint on LynxOS

  23. Naming & configuration servicesCORBA server on ORACLE Java or C++ client • Client specifies SQL query string • Hidden by CMW for naming • Can be used by CMW servers for • configuration • Data returned as Data/Data Entry CMW naming server (Java) JDBC 3-5 ms total time for simple query ORACLE

  24. User written Middleware Java Control Programs Existing or off-shelf Middleware Client API Use of CORBA Unix Workstations, Linux, Windows Naming Service CORBA Data structured into named properties Get/Set Publish CORBA Middleware Server Framework (C++) LynxOS Front-Ends Device Adapter in C Physical Device

  25. MoM Evaluation • Four test cases have been defined • Latency by message size • Latency with multiple subscribers • Latency with message filtering • Throughput • Tested JMS API compatibility on different products • Tests run under LINUX & NT • Vendors visits • JMS products can be interchanged • Performance just satisfactory • Chosen SonicMQ

  26. User written Middleware Java Control Programs Existing or off-shelf Middleware Client API CORBA CORBA Middleware Server Framework (C++) Device Adapter in C Physical Device Use of JMS JMS subscriber JMS Message Server Get/Set Device/Property Data Data structured into topics JMS publisher

  27. CERN PS SPS Alarms ST Magnet BPM Class N Magnet1 Magnet2 Device instance N CERN - wide topics hierarchy • Common root CERN • Partitioned into administration domains (PS, LHC, SPS2001, ST, Alarms ..) • Every domain defines it’s own hierarchy • All accelerator domains follow the class/device hierarchy Root Domain Class Device

  28. Outline • Presentation of the CMW project • Background and Strategy • Architecture • Solutions • What is available • Can CMW be applied elsewhere at CERN?

  29. User written Middleware Java Control Programs Existing or off-shelf Middleware Client API Middleware Server Framework (C++) Device Adapter in C Physical Device CMW current state Naming Service CORBA client adapter in Java JMS Broker Get/Set CORBA JMS message MoM Agent CORBA server adapter in C++ CORBA callback

  30. CMW to be done • PS Equipment Module support (End 2000) • SL-Equip support (End 2000) t.b.c. • OPC gateway (End 2000) • C client API (2001) • ActiveX (2001) • Other functionality from the User Requirements Document (2001)

  31. Conclusions CMW • The CMW project will fulfill the demanded functionality • Support device/property model • Support publish/subscribe (device/property & general topics) • Support inter-object communication by installing CORBA & JMS infrastructure • Support integration of industrial devices (via OPC) • Prototype available • Production version will be available End 2000 • More work to do in 2001

  32. Outline • Presentation of the CMW project • Background and Strategy • Architecture • Solutions • What is available • Can CMW be applied elsewhere at CERN?

  33. Accelerator Complex Technical Infrastructure Experiments Cryogenics From the LHC-CP workshopSeamless Data Exchange Requirements • CERN has several (middleware) Domains • Accelerators, Techn. Infrastructure, Experiments, Cryogenics • Communication requirements • Inside a domain: mostly equipment monitoring & control • Between domains: mostly information diffusion

  34. From the LHC-CP workshopInside Domain: Present Approach • Each domain uses their own Middleware solution • Accelerator Complex: PS/SL middleware project • Experiments: JCOP • ST/MO: Technical Infrastructure Monitoring (TIM) • Cryogenics: Turn-key solution • Also different solutions for: • Data model (Device-oriented or Channel-oriented) • Architecture & APIs • Technology & Implementations • Common solutions might be possible

  35. Maybe gateways needed! Accelerator Complex Cryogenics Data Interchange Bus Experiments Technical Infrastructure From the LHC-CP workshopBetween Domains: Proposed Approach A single interface to domains • A single Middleware solution (Data Interchange Bus) accepted by all domains Might use technology from one of the existing MW initiatives

  36. From the LHC-CP workshopDecisions & Activities (Incomplete List) • Decisions required • Define future of LDIWG • Define organizational scope of “LHC Middleware” (CERN groups) • Create organizational structures • Activities • Review PS/SL Middleware User Requirements in the light of LHC • Integrate other (e.g. LHC/VAC) requirements somewhere • Define functional scope of LHC Middleware (latency/throughput) • Find out about deadlines for outsourced systems • Agree on Interfaces with Inter-domain middleware • Agree on a naming scheme

  37. MOM part of CMW could be used as Data Interchange Bus • MOM is excellent for information diffusion • Loose coupling: publishers and consumers can be added at will • Scalable: message servers can be added as needed • CERN-wide topic hierarchy possible • Well integrated with WWW • Data format has to be defined: • JMS allows key-value pairs, text, binary and Java objects. • XML as subset of text is widely supported and a good candidate. • Data/DataEntry is another possibility.

  38. ST broker SL broker ST device servers SL device servers Common PLC driver approach with ST possible CMW SRFWK CMW Adapter ST PLC Agent Ethernet PLC Towards a common Middleware with ST ? • Common pub/sub API and common MOM product possible

  39. PVSS II PVSS II PVSS II PVSS to CMW mappings OPC server CMW client CMW Framework CMW-style server Can CMW be used by JCOP? • Internal JCOP Middleware is PVSS II • JCOP has to interface PVSS II to VME crates and Workstations OPC server would be required to use the CMW Server Framework from PVSS II

  40. Discussion

More Related