PVSS SOAP Interface RCMS DCS XDAQ DCS anyclient

  • Slides: 10
Download presentation
PVSS SOAP Interface RCMS DCS XDAQ DCS (anyclient PVSS) CMS week 15 -19/3/2004 Peter

PVSS SOAP Interface RCMS DCS XDAQ DCS (anyclient PVSS) CMS week 15 -19/3/2004 Peter Rosinsky, CERN PH/CMD

Motivation Ø RCMS communication with DCS Ø CMS DAQ (RCMS/XDAQ): SOAP messages (over http)

Motivation Ø RCMS communication with DCS Ø CMS DAQ (RCMS/XDAQ): SOAP messages (over http) SOAP talker/listener Ø as decoupled as possible (avoid dependencies) run on the side of PVSS Ø no native support in PVSS for external communication Ø solution: SOAP listener running as PVSS API manager Ø PSI = PVSS SOAP Interface

PSI communication CMS RCMS TK RCMS HCAL RCMS ECAL DCS BARREL HV LV ENDCAP

PSI communication CMS RCMS TK RCMS HCAL RCMS ECAL DCS BARREL HV LV ENDCAP MUON RCMS EVB RCMS ECAL DAQ BARREL ENDCAP XDAQ XDAQ XDAQ

Requirements Ø SOAP messages over http Ø read/write access (read for all) Ø logical

Requirements Ø SOAP messages over http Ø read/write access (read for all) Ø logical (Command DP+value) and raw interface Ø multiclient operation Ø synchronous operation (hide asynchronous PVSS) Ø sync GET Ø command sync with states Ø identification, authentication, security Ø performance: from few/sec to maybe ~thousands/sec (? )

PSI Features Ø commands – internal translation into DP/value Ø configurable? Ø <ON originator=“rcms

PSI Features Ø commands – internal translation into DP/value Ø configurable? Ø <ON originator=“rcms 001”/> Ø logical datapoints – serving as commands Ø <SET_DP originator=“rcms 001” dp. Name=“STATE_DP” dp. Value=“ON”/> Ø raw access – full PVSS DP name Ø <SET_DP originator=“rcms 001” dp. Name=“STATE_DP” dp. Value=“ON”/>

PSI Features Ø identification – “any” unique ID Ø hostname, node name, number Ø

PSI Features Ø identification – “any” unique ID Ø hostname, node name, number Ø originator attribute Ø ownership – for write access Ø TAKE/RELEASE commands Ø internal, or also PVSS synchonized (? ) Ø authentification – user/pwd Ø PVSS? , other? , own? Ø security – SSL Ø http server future

PSI Features 1. multiclient operation 1. keep list/stack of multiple clients’ requests accessing multiple

PSI Features 1. multiclient operation 1. keep list/stack of multiple clients’ requests accessing multiple DPs 2. synchronous GET 1. send in the response message the value obtained asynchronously by PVSS 2. allows “synchonous” polling 3. command-state synchronization 1. response message sent only after certain state is reached 2. allows “synchronous” commads inside the client 1. native for RCMS/XDAQ

Implementation Ø EHS http server (pure C++) Ø embedded PVSS http server foreseen later

Implementation Ø EHS http server (pure C++) Ø embedded PVSS http server foreseen later Ø “any” PVSS version Ø XOAP - Xerces (DOM parser) Ø client-specific commands (RCMS) Ø Linux only for the moment

RCMS DCS interface 1. state commands (ON/OFF/STANDBY) via logical datapoint 1. “standard” <set. Parameter

RCMS DCS interface 1. state commands (ON/OFF/STANDBY) via logical datapoint 1. “standard” <set. Parameter … /> command (? ) 2. <set. Parameter originator=“rcms 001” dp. Name=“STATE_DP” dp. Value=“ON”/> 2. synchronous GET for polling 1. so that RCMS does not need a special listener 3. no SUBSCRIBE (at least for the moment) 1. since it needs another listener 4. command-state synchronization 1. e. g. RCMS sends “ON” command – response comes only when the ON state is really reached

Conclusions 1. basics of the interface defined and implemented 2. prototype working 1. RCMS

Conclusions 1. basics of the interface defined and implemented 2. prototype working 1. RCMS FM can set and read the PVSS state DP 2. using Run. Control applet TO DO: 1. finalize the message format and requirements (~this week) 2. finalize the interface and the RCMS (Java) client library (~next week) 3. port and test in Windows 4. identification, authentification, security 5. further clients, requirements