OBJECTIVE OF THE MEETING

As explained during the first LHC-CP project workshop, the subject of Middleware for LHC is considered as a key element with high priority of the future control system architecture.

During the workshop, the summary of the Middleware session outlined the need for:

· Taking strategic decision and putting in place an organizational structure steered by LHC-CP

· Reviewing the PS/SL Middleware project in the light of the LHC requirements

· Encourage convergence and avoid diversity for aspects related to data models, naming schemes, interfaces and integration of industrial components and DCS

This meeting was aimed at looking for a possible convergence between the middleware approaches for the accelerator control and for the technical infrastructure monitoring.

REASONS FOR CONVERGENCE

Very often, presentations on Middleware tend to show the technical services infrastructure monitoring and the accelerator control as two entirely separated domains which needs to be connected in a way or another. In reality, from both the operational and technical point of view, the technical sector and the accelerator sector have many aspects in common:

· Both use, since many years, the same major services of the control system. Typical examples are the CERN Alarm System and the Logging System. In addition, they share access to a very large number of equipment devices (i.e. all LEP services) controlled from the SL/CO front-end computers.

· In case of major incident on the technical infrastructure used by the accelerators, the PCR and the TCR collaborate closely, using the same software, to restore a stable situation. Correlation of machine parameters with technical data is also very frequent.

· Both have or are looking for a MW solution based on industry standards and offering good guarantees of availability and reliability

· Both consider the need for having ONE policy for interfacing the industrial components and SCADA systems to the Middleware

· Both share the same opinions (from a wide perspective – at least) about :

· The Middleware technology to be used for exchanging information : Message Oriented Middleware supporting the Publish/subscribe paradigm

· The need for sharing a common name space (i.e. TCR could easily subscribe to “subjects” of information from the accelerator and vice-versa)

· The advantage of using the same Middleware API (application Programming interface), preferably based on industry standards (i.e. Java Messaging Service), provided it offers the desired level of reliability

PROPOSAL TO THE LHC-CP PROJECT

Members present during this meeting propose the following scenario to the LHC-CP project:

· Change the mandate (and name ?) of the present PS/SL Middleware project in order to :

· redefine clearly the objectives to be attained for LHC (reminder : the PS/SL Middleware project was launched under the auspices of the PS/SL Convergence project, with no direct link to the LHC requirements)

· Verify the role of the middleware within the global architecture considering the services that it shall provide

· Stress the importance of finding ONE common approach for interfacing industrial components and SCADA to our control system

· Start a close collaboration with the Technical Sector (ST/MO). Join their Middleware experience with the new concepts developed in the current PS/SL middleware project and take common choices and/or decisions in terms of :

· Interfaces

· Commercial MOM products selection

· Configuration and management

· Diagnostic facilities

· Name space (subjects hierarchies)

· Interfaces with industrial components and SCADA

· Define the LDIW phase II mandate in the light of the communication needs with the LHC experiments and all problems related to the configuration of the information to be exchanged (coherency) and the data exchange formats to be used (i.e. XML, …)

Various stages of middleware convergence can be considered from the use of identical documented interfaces up to the use of the same under-laying industrial product.

Nevertheless, the participants are convinced that this approach will optimize the financial and human resources involved in the design and maintenance of the control & monitoring system. Moreover, it will ease operation by minimizing the heterogeneity of the information used by the PCR and TCR control rooms.