Controls Middleware (CMW) Presentation to the Controls Board

Controls Middleware(CMW)

Presentation to the Controls Board

The Middleware TeamOctober 31, 2000

From CB Mandate:

To promote a common approach in controls activities at CERNTo recommend to the Technical Director standard solutions for controls at CERNTo ensure regular communications between the controls teams at CERNTo promote collaborations in controls projects at CERN

Observe the trends in controls at CERNSet up working groups to prepare general recommendations in controlsCreate 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 projectBackground and StrategyArchitectureSolutionsWhat is available

Can CMW be applied elsewhere at CERN?

The PS/SL Middleware Project

MandateLaunched in early 1999 as PS/SL collaboration to provide communication infrastructure for existing accelerators

MembersPS/CO: Steen Jensen, Alessandro Risso, Nikolai TrofimovSL/CO: Vito Baggiolini, Francois Chevrier, Francesco Calderini, Kris Kostro, Marc Vanden Eynden

Recent collaboration with ST suggested by LHC-CP

CMW RequirementsHigh-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 devicesUltimately replace existing PS and SL communicationRely on available standards

Detailed requirements published in August 1999www.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 OverviewMarch 1999Workshop on MW technologies

August 1999Requirements from PS/SL control & equipment

groups publishedAutumn 1999Selection of technology

January 2000Technical choices published in the “Whitepaper”

Spring 2000Elaboration of Architecture and APIs

Summer 2000Prototype developed

End 2000 in operation

Outline



Design principles

Technology independentOne stable public interfaceUse standardsUse 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 layerDevice/property model, get/set, pub/sub, complex data

User software or API

(PS, PS Timing, SPS2001, CESAR, Alarms)

Modular API layeringUser written

CMW

Existing or off-shelf

Public CMW API

Private CMW API’s

StandardAPI’s

Device/Property ModelControl 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, unsubscribeDevices organized into device classesThis model is similar to Java Beans

Device and Data model

name : String

Device Class Device Property

name : String

0..n1

DataEntry

Typed method toinsert and extractvalues

0..nData

add(entry: DataEntry)..

Conceptual model

Programming model

Device

name : String

get(property): Dataset(property, Data)monitorOn(prop, Listener)monitorOff(property)

Device Adapter

MiddlewareServer Framework

Physical Device

User written

Middleware


LynxOSFront-Ends

Controls Programs

MiddlewareClient API

Unix Workstations,Linux, Windows

Get/Set PublishData structured

into namedproperties

General Communication Model

Outline



OO CommunicationOO RPC

CORBAJava RMIDCOMSOAP (XML-based)

OO MOMJava JMS

Chosen TechnologyCORBA for Set/Get

“Object-Oriented RPC”Available on multiple platforms & languages

MoM for Publish/SubscribeSupport for the Java Message Service (JMS) APIPublication of data to a “topic”

CORBA MoM

Why both CORBA and MOM ?“le meilleur de deux mondes”

CORBA is the only fully interoperable MWAny languageAny systemMany products

BUT

MOM scales betterMOM is excellent for loosely coupled systems

Producer only needs to know the subjectConsumer only needs to know that a subject exists

Evaluated Products

CORBAHARDPack (Lockheed Martin/USA)omniORB2 (AT&T/UK)ORBexpress (OIS/USA)ORBacus (OOC/USA)

MoMIBUS (SoftWired/CH)SmartSockets (Talarian/USA)SonicMQ (Progress Software/USA)

CORBA evaluationInteroperability

Java/C++, Linux/LynxOS, Naming Service

Performance2-3 ms for Java to Java call0.078 ms have been reported for a product168K footprint on LynxOS

Naming & configuration services CORBA server on ORACLE

Java or C++client

CMW namingserver (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

CORBA

User written

Middleware


Device Adapter in C

MiddlewareServer Framework (C++)

Physical Device

LynxOSFront-Ends

Java Control Programs


Unix Workstations,Linux, Windows

Get/Set Publish

Data structuredinto namedproperties

Use of CORBA

NamingService

MoM EvaluationFour test cases have been defined

Latency by message sizeLatency with multiple subscribersLatency with message filteringThroughput

Tested JMS API compatibility on different productsTests run under LINUX & NTVendors visits

JMS products can be interchangedPerformance just satisfactory

Chosen SonicMQ

User written

Middleware

Existing or

off-shelf

CORBA

Device Adapter in C


Physical Device

CORBA



Get/Set

Device/PropertyData

Use of JMS

JMS MessageServer

JMSpublisher

Data structuredinto topics

JMSsubscriber

CERN - wide topics hierarchy

Common root CERNPartitioned into administration domains (PS, LHC, SPS2001, ST, Alarms ..)Every domain defines it’s own hierarchyAll accelerator domains follow the class/device hierarchy

CERNCERN

SPSSPS AlarmsAlarms

MagnetMagnet BPMBPM Class NClass N

Magnet1Magnet1 Magnet2Magnet2 Device instance NDevice instance N

STSTPSPS

Root

Domain

Class

Device

Outline



CORBA client adapter in Java

User written

Middleware


Device Adapter in C


Physical Device



Get/SetCORBA

MoMAgent

CORBA callback

JMS message

CMW current state

NamingService

CORBA server adapter in C++

JMSBroker

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 modelSupport publish/subscribe (device/property & general topics)Support inter-object communication by installing CORBA & JMS infrastructureSupport integration of industrial devices (via OPC)

Prototype availableProduction version will be available End 2000More work to do in 2001

Outline



From the LHC-CP workshopSeamless Data Exchange

Requirements

CERN has several (middleware) Domains Accelerators, Techn. Infrastructure, Experiments, Cryogenics

Communication requirementsInside a domain: mostly equipment monitoring & control Between domains: mostly information diffusion

ExperimentsTechnical

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 projectExperiments: JCOP ST/MO: Technical Infrastructure Monitoring (TIM)Cryogenics: Turn-key solution

Also different solutions for:Data model (Device-oriented or Channel-oriented)Architecture & APIsTechnology & 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

Da

ta In

terc

han

ge B

us

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

ActivitiesReview PS/SL Middleware User Requirements in the light of LHCIntegrate other (e.g. LHC/VAC) requirements somewhereDefine functional scope of LHC Middleware (latency/throughput)Find out about deadlines for outsourced systems Agree on Interfaces with Inter-domain middlewareAgree on a naming scheme

MOM part of CMW could be used as Data Interchange Bus

MOM is excellent for information diffusionLoose coupling: publishers and consumers can be added at willScalable: message servers can be added as neededCERN-wide topic hierarchy possibleWell 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

STbroker

SLbroker

ST device servers SL 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 IIJCOP 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

PVSS II

PVSS II

CMW-styleserver

CMW Framework

OPC server

CMW client

PVSS to CMWmappings

Discussion

Controls Middleware (CMW) Presentation to the Controls Board

Documents

Transcript of Controls Middleware (CMW) Presentation to the Controls Board