AB Controls | SL Controls | PS Controls | LHC-CP | ST Controls

Present: All members of the core team; Andy Butterworth SL/RF, Etienne Carlier SL/BT, Mike Clayton SL/CO, Pierre Charrue SL/CO, Philipp Cregeen SL/CO, Jan Cuperus PS/CO, Arend Dinius SL/PO, Jean-Jacques Gras SL/BI, Quentin King SL/PO, Julian Lewis PS/CO, Pierre Ninin ST/MO, Pedro Ribeiro SL/CO, Peter Sollander ST/MO, Pierre Strubin LHC/VAC, Mark Tyrrell SL/CO.

Goal of this meeting

• Present the middleware project and its background to the potential members of the client and soft team.
• Receive first feedback from the audience, and answer questions.
• Obtain a first statement about people who want to participate in the project.

1. Presentation by Kris Kostro

Kris first recalled the background of the Middleware (MW) project (PS/SL Convergence, SPS-2001). Then, he introduced the JavaAPI and the Device Model, and gave an overview over candidate MW solutions. Finally, he briefly presented the "Goal Directed Project Management" method that shall be used for this project.

The slides of the presentation will be soon available on the Web.

2. Feedback from the Audience

This section is presented in a Q&A fashion. The questions were asked by the audience, the answers partly came from the MW core team, partly from the audience. We reorganized questions to their subject. This is the basis for the MW FAQ that will be extended in future.

Device Model & JavaAPI

• Q: In which machines is the device abstraction layer located?
• A: Anywhere: Front-ends, ROCS, HP's.
 
• Q: Are you going to use the same device model in PS and SL? Shall there be a common implementation also "below" the MW?
• A: The device model shall be the same, but the class hierarchy that represents the devices and its implementation shall be different between PS and SL.
 
• Q: What do you provide in addition to the MW?
• A: On the client side the JavaAPI will be implemented on top of the MW; on the server side, we will provide support to the equipment groups for facilitating server integration.
 
• Q: What kind of software shall run on top of the JavaAPI?
• A: Any new program should access the equipment and the control system through the new JavaAPI. Old systems will of course continue to be supported by SL_Equip.

Performance

• Q: Are you sure that a MW solution will provide the necessary performance?
• A: We need performance requirements from the users. Anyway, the new system is expected to have at least the performance of the present SL_Equip solution. The publish-subscribe facility of the new system is expected to further enhance performance. Performance shall be practically validated through the implementation of prototypes.

CORBA

• Q: Is CORBA stable? Is the market ready? Is there a risk that CORBA is going to disappear or become a dead end in 15 years time?
• A: It is difficult to predict 15 years. But it is unlikely that CORBA disappears, since it is supported by a consortium of 800 firms, and founded 1989. In any case, in PS/SL there is an important move towards object-oriented techniques which has to be supported by suitable MW.
 
• Q: Are the different implementations of CORBA compatible? And what about interoperability with COM/DCOM?
• A: CORBA version 2 claims to be compatible, and there is support for DCOM. However, that has to be verified.

Java

• Q: Does Java have a fundamental role in the MW project? Isn't there a risk that it fractions? What about it's performance?
• A: Java is an important language, but this project is not restricted to Java. Languages can be changed relatively easily; what is important is that we have a stable (device) model on which all agree.

Naming and addressing databases

• Q: How do databases fit into that? Where is the low-level information about addressing, etc. stored?
• A: Addressing should be transparent to the client (JavaAPI) side, so that low-level equipment can be exchanged without the clients noticing. However, the technical realization of this issue has to be further studied. It must be investigated how the general databases and database services provided by MW solutions (e.g. naming and trading) can be used for that purpose.

Industrial systems

• Q: What about industrial systems?
• A: The communication with industrial systems (String 2) is part of this project. OLE for process control (OPC) is being studied in the JCOP project. Their results shall be integrated with our work.

Migration

• Q: What about migration?
• A: Migration is an important issue, which has to be addressed during the project.

One of the effects of this is that for a certain time a dual infrastructure has to be in place. It has to be investigated how this additional load affects the front-ends.
 
• Q: What percentage of software has to be rewritten?
• A: The new API's only concern new software. MW does not address rewriting of applications. However, CORBA made for integration of legacy, which should allow for a gradual migration.

Organizational Issues

• Q: How does this integrate with other MW activities at CERN, namely the LHC Systems Data Interchange WG (LDIWG)?
• A: The LDIWG studies the inter-data exchange between accelerators, experiments and services. It will identify what data has to be exchanged, its direction and frequency, etc. The MW project provides mechanisms for data exchange and control within the accelerator control system. We shall collaborate with them in order to coordinate our activities. A member of the MW core team is also a member of the LDIWG, thus acting as a link person.
 
• Q: It seems that this working group makes technology choices before having requirements…
• A: JavaAPI already defines an important number of requirements. But we continue to gather requirements and users are encouraged to contribute. We have to get acquainted with commercial MW solutions that are around. At a certain point, an unbiased match will be made between requirements and available MW solutions.

3. Tour de table

Every person present was asked how they saw their role in the MW project: whether they wanted to participate in the definition of the project strategy, the gathering of requirements and in implementation. Which (if any) of the three project teams (core, soft, client) they wanted to join.
 

Andy Butterworth	Would like to participate in strategy and requirements, as a member of the client team. However, as he still works in LEP, he must either get a mandate or motivate his colleagues to participate in the MW project.
Etienne Carlier	Joins the client team, wants to ensure compatibility of the MW with the part of the system he is responsible for (Kickers SPS/LHC). Does not participate in strategy definition.
Pierre Charrue	Is the project leader of SPS-2001, and participates in the client team.
Mike Clayton	Would like to participate in the application of the middleware project to the SPS Experimental Areas, but will not be able to do this until after the startup.
Jan Cuperus	As a member of the Java API project, he wants to follow closely the work done in the MW WG, and actively participate in the implementation of the JavaAPI generic layer on top of the MW.
Jean-Jacques Gras	Wants to actively participate in project strategy, BI requirements gathering, and also in testbedding on a BI instrument. Joins the client team.
Quentin King	Contributes a paper from which requirements can be derived. Does not participate in strategy definition. Would like to participate in checkpoints to make sure that MW is compatible with his work.
Julian Lewis	Wants to participate in strategy and requirements gathering, especially for the event distribution and change/subscription work. Is already strongly involved with convergence, where he participates in the timing WG.
Pierre Ninin	Wants to make sure that the new MW integrates well with their current system. Participates in strategy and in requirements gathering for this integration part.
Pedro Ribeiro	As a responsible of the FE section, he wants to make sure that the MW is compatible with the front ends. Participation in the soft team.
Peter Sollander	Sees himself as a link person with ST/MO, to ensure compatibility with their systems.
Pierre Strubin	Is interested in the outcome of the project rather than in actively participating in it. Sees himself as an end user.
Mark Tyrrell	Is interested in a middleware facility to 'publish' & 'subscribe' alarm information at the 'atomic' & 'abstraction' level. Participates in: definition of project strategy; input to requirements; implementation & testing. Joins the 'soft' & 'client' teams.

 

4. Actions

The core team has to prepare a working meeting in which the milestone and activity plans shall be established together with the members of client team and soft team.
 
Vito Baggiolini SL/CO