Controls Middleware (CMW) Presentation to the Controls Board The Middleware Team October 31, 2000
Jan 31, 2016
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?
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
Presentation of the CMW projectBackground and StrategyArchitectureSolutionsWhat is available
Can CMW be applied elsewhere at CERN?
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
Existing or off-shelf
LynxOSFront-Ends
Controls Programs
MiddlewareClient API
Unix Workstations,Linux, Windows
Get/Set PublishData structured
into namedproperties
General Communication Model
Outline
Presentation of the CMW projectBackground and StrategyArchitectureSolutionsWhat is available
Can CMW be applied elsewhere at CERN?
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
Existing or off-shelf
Device Adapter in C
MiddlewareServer Framework (C++)
Physical Device
LynxOSFront-Ends
Java Control Programs
MiddlewareClient API
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
MiddlewareServer Framework (C++)
Physical Device
CORBA
Java Control Programs
MiddlewareClient API
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
Presentation of the CMW projectBackground and StrategyArchitectureSolutionsWhat 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
MiddlewareServer Framework (C++)
Physical Device
Java Control Programs
MiddlewareClient API
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
Presentation of the CMW projectBackground and StrategyArchitectureSolutionsWhat is available
Can CMW be applied elsewhere at CERN?
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