architectural issues m.jonker. things to do md was a success. basic architecture is satisfactory....

8
Architectural issues M.Jonker

Upload: cuthbert-copeland

Post on 19-Jan-2016

212 views

Category:

Documents


0 download

TRANSCRIPT

Architectural issues

M.Jonker

Things to do

MD was a success.Basic architecture is satisfactory.

This is not the end:• Understanding of actual technical issues• Missing functionality• Integration with LSA (S.Redaelli)

• Integration with Machine protection and Critical Settings. (R.Assmann)

• Fesa Server streamlining / Integration Low Level / CSS• Support from CO, PXI and others• Temperature readout (continued support by CO)• Test Bed systems• Integration of other moveable objects into this control system.

Technical issues

Understanding of performance issues– System response and Time stamping– Originating in external environment

• Need attention of the CO responsible

– Hanging of Java application• Need to recreate the condition and analyse this

with the help of CO experts.

Not an issue, can be dealt with. (No need for decisions here).

Missing FunctionalityStill to implement:– Position Functions (all levels)– Position surveillance (low level)– Detection (correction?) of lost position knowledge– Machine protection issues, critical settings

• To be reviewed in spring 2007

– Post Mortem• Post Mortem workshop January

– Retriggerable movements at low level– BLM based optimization

CSS streamlining

CSS

PC gateway

PXI

FESA motorsinterface

BLM crate

Java GUI Logging DB Files

FESA interface

supervisordiagnostics

synchro motors BLM trans.

CTRI

Maciej has already presented ideas on further streamlining the CSS.

Also need to discuss integration of low level Fesa Motor interface with CSS.• No added value in

functionality.

• Longer control path

• Dependence on various experts.

Collaboration of ATB/CO• Contributions from ATB

• Final responsibility with CO

• Shared knowledge

• Shared expertiseConvergence of CSS solutions with Fesa architecture.In collaboration with the with Fesa Team

PXI supportPXI to be seen as a black box, what are the support needs from CO?

Co services:– Procurement, installation, management of spares

Not offered for PXI, will be supported by ATB.

– Configuration ManagementSimple and fixed configuration: we can survive without configuration DB services.

– Driver developmentAll drivers are provided and supported by NI

– Operating system supportIdem. Stable OS with very infrequent updates

– PXI FESA communicationBased on Dim (a cern middleware) supported by IT/CO and by NI.NI will offer an alternative next spring (to be validated)Second (and not considered) alternative: Replacement with a peer to peer communication (e.g. like ieplc)

– Critical Settings handling in PXIPossibly help required to provide/implement/support the signature validation code.

FutureNeed a permanent test beds for control system

Building 252 (collimator lab):– Development of low-level system and CSS

Installed Collimators in TI & LHC:– Test and development of CSS and CCC application

(integration with LSA).

Need final hardware soon!

LSS5 Collimator– Test of BLM connection and response.– Any more MD planned? An upgrade of the hardware

would be welcome!

Other moveable objectsWe are not alone… (i.e. there are also the others:

– TCDQ, TCDI

– Roman pots (Totem, Atlas)

They need to be integrated coherently into the control system for moveable objects.

Minimum requirement: a Fesa server compatible with CSS.

To avoid development of dedicated control software, we recommend to also use the same hardware solution down to the PXI system.

For experiments: experiments still stay responsible for installation, commissioning, tests, first line diagnostics.

TCDQ uses a DC motor. Possible to interfaced with the stepping motor controller. Option under investigation with E.Carlier, B.Goddart