Transcript middleware

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, SPS2001, 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)
monitorOn(prop, Listener)
monitorOff(property)
1
Device Class
name : String
Data
0..n Device Property
name : String
DataEntry
0..n
add(entry: DataEntry)
.
.
Typed method to
insert and extract
values
General Communication Model
User written
Controls Programs
Middleware
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
LynxOS
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
MoM for Publish/Subscribe
Support for the Java Message
Service (JMS) API
Publication of data to a “topic”
MoM
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
omniORB2
ORBexpress
ORBacus
(Lockheed Martin/USA)
(AT&T/UK)
(OIS/USA)
(OOC/USA)
MoM
IBUS
SmartSockets
SonicMQ
(SoftWired/CH)
(Talarian/USA)
(Progress Software/USA)
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
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
Unix
Workstations,
Linux, Windows
Middleware
Client API
Existing or offshelf
CORBA
Get/Set
Naming
Service
Data structured
into named
Publish
properties
CORBA
Middleware
Server Framework (C++)
Device Adapter in C
Physical Device
LynxOS
Front-Ends
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
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
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, SPS2001, ST, Alarms ..)
Every domain defines it’s own hierarchy
All accelerator domains follow the class/device hierarchy
CERN
PS
SPS
Magnet
Magnet1
Alarms
BPM
Magnet2
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
Middleware
Client API
Existing or offshelf
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
MoM
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)
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
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/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 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
PVSS II
OPC server
CMW client
OPC server would be required to
use the CMW Server Framework
from PVSS II
PVSS II
CMW
Framework
CMW-style
server
PVSS
to CMW
mappings
Discussion