80 likes | 229 Views
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)
E N D
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 Functionality Still 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
Java GUI Logging DB Files FESA interface diagnostics supervisor synchro motors BLM trans. BLM crate CTRI FESA motors interface CSS streamlining • 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 expertise PC gateway CSS PXI Convergence of CSS solutions with Fesa architecture. In collaboration with the with Fesa Team
PXI support PXI 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 Management Simple and fixed configuration: we can survive without configuration DB services. • Driver development All drivers are provided and supported by NI • Operating system support Idem. Stable OS with very infrequent updates • PXI FESA communication Based 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 PXI Possibly help required to provide/implement/support the signature validation code.
Future Need 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 objects We 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