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 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 1999 www. cern. ch/controls-middleware

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 2000 www. cern. ch/controls-middleware 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

Modular API layering User written CMW User software or API Existing or off-shelf (PS, PS Timing, SPS 2001, CESAR, Alarms) Public CMW API 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) 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 Conceptual model Programming model Device name : String get(property): Data set(property, Data) monitor. On(prop, Listener) monitor. Off(property) 1 Device Class name : String Data 0. . n Device Property name : String Data. Entry 0. . n add(entry: Data. Entry). . Typed method to insert and extract values

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

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 CORBA Mo. M for Publish/Subscribe Support for the Java Message Service (JMS) API Publication of data to a “topic” Mo. M

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 omni. ORB 2 ORBexpress ORBacus (Lockheed Martin/USA) (AT&T/UK) (OIS/USA) (OOC/USA) Mo. M IBUS Smart. Sockets Sonic. MQ (Soft. Wired/CH) (Talarian/USA) (Progress Software/USA)

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

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

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

Mo. M 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 Sonic. MQ

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

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

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

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

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) Active. X (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 Accelerator Complex Technical Infrastructure Experiments 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 Accelerator Complex Technical Infrastructure Might use technology from one of the existing MW initiatives Data Interchange Bus A single interface to domains Maybe gateways needed! Cryogenics Experiments

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/Data. Entry is another possibility.

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

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

Discussion