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 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

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?

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

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

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

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

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

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 contains documentation, papers, minutes

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

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

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

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

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

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

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

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

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

Chosen Technology 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” CORBAMoM

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

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)

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

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

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

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

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

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 CERN SPS Alarms Magnet BPM Class N Magnet1 Magnet2 Device instance N ST PS Root Domain Class Device

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

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

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)

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

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

From the LHC-CP workshop Seamless 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 Experiments Technical Infrastructure Accelerator Complex Cryogenics

From the LHC-CP workshop Inside 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

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

From the LHC-CP workshop Decisions & 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

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.

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

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 PVSS II CMW-style server CMW Framework OPC server CMW client PVSS to CMW mappings

Discussion