LHCCP Working Session on Middleware Participants: D. Myers, C.-H. - - PowerPoint PPT Presentation

lhccp working session on middleware
SMART_READER_LITE
LIVE PREVIEW

LHCCP Working Session on Middleware Participants: D. Myers, C.-H. - - PowerPoint PPT Presentation

LHCCP Working Session on Middleware Participants: D. Myers, C.-H. Sicard, U. Epting, K. Kostro, J.-J. Gras, I. Laugier, A. Risso, E. Ciapala, F. Calderini, V. Baggiolini Outline Scope of the working session Definition of


slide-1
SLIDE 1

LHCCP Working Session on Middleware

Participants:

  • D. Myers, C.-H. Sicard, U. Epting,
  • K. Kostro, J.-J. Gras, I. Laugier, A. Risso,
  • E. Ciapala, F. Calderini, V. Baggiolini
slide-2
SLIDE 2

Vito Baggiolini, SL/CO

2

Outline

  • Scope of the working session

– Definition of “Middleware”

  • Inventory of ongoing middleware activities

– Clients & Users – Middleware initiatives

  • How to achieve “seamless data exchange”

– Scope & Requirements – Solution approaches – Issues & Challenges

  • Organization

– Division of work – Collaborations

  • Required decisions & activities
  • Conclusions
slide-3
SLIDE 3

Vito Baggiolini, SL/CO

3

Scope of the session

  • Middleware (Definition for this session:)

– “communication glue between distributed software components” – functionality to exchange data and commands between different parts of a distributed control system – functionality for information diffusion

  • We did not discuss

– Database access – Software development environment – Hardware platforms – Network & Fieldbus infrastructure – etc. etc.

  • No detailed technical discussions
slide-4
SLIDE 4

Vito Baggiolini, SL/CO

4

Outline

  • Scope of the working session

– Definition of “Middleware”

  • Inventory of ongoing middleware activities

– Clients & Users – Middleware initiatives

  • How to achieve “seamless data exchange”

– Scope & Requirements – Solution approaches – Issues & Challenges

  • Organization

– Division of work – Collaborations

  • Required decisions & activities
  • Conclusions
slide-5
SLIDE 5

Vito Baggiolini, SL/CO

5

Inventory: Middleware Clients & Users (1)

  • LHC/VAC: (I. Laugier) Control of all vacuum equipment

– Communication with 3 vacuum systems; Mobile systems – 50 readings/sec, precise timestamps, – Data exchange with cryogenics and beam measurement – Introducing PLCs now

  • SL/RF (E. Ciapala): RF System for LHC

– Acceleration, Damping and Beam control – Monitoring & control, various data formats, large blocks of data – Access control, control priorities, tracing of actions – PLCs and in-house equipment controllers – Users of PS/SL middleware

slide-6
SLIDE 6

Vito Baggiolini, SL/CO

6

Inventory: Middleware Clients & Users (2)

  • SL/BI (J.-J. Gras): Beam Instrumentation Software

– GUIs, Server software, drivers; Logging & RT feedback – Communication between the above and with external world – Want to use PS/SL middleware and contribute to its success – Will develop own facilities (only when needed)

  • Alarms SL/CO (F. Calderini): CERN-wide alarm distribution

– Use case: users subscribe to groups of fault states (“subjects”) – Reliability, availability, traceability; Bursty traffic, not time critical – 3-tier architecture using open message-oriented middleware – Active collaboration with PS/SL middleware project & LDIWG

  • (There are certainly others...)
slide-7
SLIDE 7

Vito Baggiolini, SL/CO

7

Inventory: Middleware Initiatives (1)

  • ST/MO, (U. Epting) Technical Infrastructure Monitoring

– TCR: Monitoring 24h/day; 365days/year; troubleshooting coordin. – Integration of many diverse systems (in-house, PLC, SCADA) – Data exchange with external world – message-oriented middleware; Participation in LDIWG

  • JCOP: Controls for LHC experiments

– Distributed control system based on SCADA – Middleware: OPC for industrial; DIM for custom developments – Communication with LHC machine, Safety system, Cryogenics, etc => LDIWG

  • PS/SL Middleware project: MW for PS&SL accelerators

– Requirements from PS/SL equipment groups – Selection of technology: CORBA & Message-Oriented Middleware – Elaboration of Architecture and Interfaces – Prototypes for Summer ‘00, first production software December 00

slide-8
SLIDE 8

Vito Baggiolini, SL/CO

8

Inventory: Middleware Initiatives (2)

  • LHC Data Interchange WG (C.-H. Sicard):

– CERN-wide LHC data exchange – Participants: Accelerators, Experiments, ST, Cryogenics, etc. – Requirements for LHC data exchange

  • Communicating entities
  • Data exchanged & Traffic characteristics

– Overall Architecture – Phase 2: strategies for implementation

slide-9
SLIDE 9

Vito Baggiolini, SL/CO

9

Outline

  • Scope of the working session

– Definition of “Middleware”

  • Inventory of ongoing middleware activities

– Clients & Users – Middleware initiatives

  • How to achieve “seamless data exchange”

– Scope & Requirements – Solution approaches – Issues & Challenges

  • Organization

– Division of work – Collaborations

  • Required decisions & activities
  • Conclusions
slide-10
SLIDE 10

Vito Baggiolini, SL/CO

10

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 Experiments Technical Infrastructure Accelerator Complex Cryogenics

==> Two logical levels of Middleware

slide-11
SLIDE 11

Vito Baggiolini, SL/CO

11

Intra-domain vs. Inter-domain: Requirements

Intra-domain

  • Monitoring & Control
  • High traffic rate
  • Low latency required
  • Specialized, “agreed-on” data
  • Close coupling between

communicating entities

Inter-domain

  • Information diffusion
  • Lower traffic rate
  • Higher latency acceptable
  • Self-describing data
  • Loose coupling between

communicating entities Experiments Technical Infrastructure Accelerator Complex Cryogenics

slide-12
SLIDE 12

Vito Baggiolini, SL/CO

12

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
slide-13
SLIDE 13

Vito Baggiolini, SL/CO

13

Between Domains: Proposed Approach

  • A single Middleware solution (Data Interchange Bus)

accepted by all domains

Data Interchange Bus Accelerator Complex Technical Infrastructure Cryogenics Experiments

  • A single interface to

domains

  • Maybe gateways needed!
  • Might use technology from one
  • f the existing MW initiatives
slide-14
SLIDE 14

Vito Baggiolini, SL/CO

14

Issues & Challenges

  • Mapping between data models

– channel-oriented <=> device-oriented <=> “subject-oriented”

  • Common naming schemes

– (what are naming schemes?)

  • Definition of common interfaces

– Agree on: APIs, Protocols, data representations

  • Integration of different entities & technologies

– Industrial/OPC + Unix/CORBA/MoM

Organizational (“human”) aspects are more difficult than technical ones!

slide-15
SLIDE 15

Vito Baggiolini, SL/CO

15

Outline

  • Scope of the working session

– Definition of “Middleware”

  • Inventory of ongoing middleware activities

– Clients & Users – Middleware initiatives

  • How to achieve “seamless data exchange”

– Scope & Requirements – Solution approaches – Issues & Challenges

  • Work Organization

– Division of work – Collaborations

  • Required decisions & activities
  • Conclusions
slide-16
SLIDE 16

Vito Baggiolini, SL/CO

16

Work Organization

  • Division of Middleware work

– Inter-domain Middleware => LDIWG-2 – Accelerator Middleware => PS/SL Middleware project – Infrastructure monitoring Middleware => ST/MO TIM – Experiment Middleware => JCOP – Alarms, Cryo, Vac, Equipment Grps => Choose your MW partner!

  • Collaboration areas

– Definition of (inter-domain) Interfaces – Naming conventions – Selection & support of middleware technology – Gateways OPC – Corba/MoM – Implementation of components

  • An organizational structure has to be put in place!

– LDIWG-2? LHC-CP sub-project? Other?

slide-17
SLIDE 17

Vito Baggiolini, SL/CO

17

Outline

  • Scope of the working session

– Definition of “Middleware”

  • Inventory of ongoing middleware activities

– Clients & Users – Middleware initiatives

  • How to achieve “seamless data exchange”

– Scope & Requirements – Solution approaches – Issues & Challenges

  • Organization

– Division of work – Collaborations

  • Required decisions & activities
  • Conclusions
slide-18
SLIDE 18

Vito Baggiolini, SL/CO

18

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

slide-19
SLIDE 19

Vito Baggiolini, SL/CO

19

Conclusions

  • A lot has been already done

– Intra-domain: Requirements, Technology selection, Architecture – Inter-domain: Requirements and Architecture (LDIWG)

  • 3 Practical Middleware Initiatives with man-power

– TIM (ST/MO), JCOP, PS/SL Middleware

  • Accelerator Domain: PS/SL Middleware is the candidate
  • Organization

– Work distribution is relatively straight-forward – Collaborations are possible but need to be encouraged – Organizational structure is required

  • Many Thanks to the working session participants!