TC 25th October1 Real-time A system -- e.g., application system, computer system, operating system -- operates in real time to the degree that those of its actions which have time constraints are performed with acceptable timeliness. These actions' timeliness and timeliness acceptability are typically part of the system's behavioral requirements (and often even part of its logic) -- thus, they are objectively quantifiable and measurable. The degree to which a system operates in real time is achieved by some combination of explicit and implicit means. A system is real-time to the degree that it employs real-time resource management -- i.e., its resources are explicitly managed for the purpose of operating in real time. This resource management may be performed statically off-line or dynamically on-line. The degree to which a system is real-time is a means rather than an end, and thus typically is not specified as a requirement. The degree to which a system is real-time can be quantified in different ways but hasno widely accepted metric, and thus is usually subjective.

TC 25th October2 Real-time A system may operate in real time to some (perhaps very high) degree by implicit means -- hardware resource over-capacity, or good fortune. Real-time resource management exacts a variety of costs which are not declining as rapidly as are hardware resource costs. But the degree to which a system is required to operate in real time cannot necessarily be attained solely by hardware over-capacity (e.g., high processor performance) without any real-time resource management. Each particular system which must operate in real time needs an appropriate balance of real-time resource management and hardware resource capacity.

TC 25th October3 Why? So we have large multipole swings during the injection plateau and snapback... Beam stability will depend totally on –feed-forward from the reference magnets –feedback on the key beam parameters tune, orbit, energy, chromaticity Have to make a phase jump in our expected performance of a control system: We will need similar to deal with multipoles, tight physics constraints & the low tolerance to beam loss.

TC 25th October4 RT Requirements Reference magnets –feed-forward of corrections to machine Feedback-loops –Global Orbit –Local Orbit - e.g. orbit stability at collimators –Tune –Chromaticity Real-time knobs –typically tune, orbit bumps –extension of feedback, operator close loop, need... Display –Orbit –Beam loss (not for abort, but display & possible feedback) –Luminosity, Beam sizes, Lifetimes… Timing like actions (possibly), synchronization –e.g post-mortem trigger, injection

TC 25th October5 RT requirements II Response limited by PC/magnet

TC 25th October6 Implications I need to –acquire data from distributed front-ends and –process this date at the high level –and send corrections to distributed devices –at x Hz. (looks like a minimum of 10 Hz) Need a general solution (not SISO but MIMO) Some real-time resource management as opposed to over capacity

TC 25th October7 Implications BI –orbit, BLM, chromaticity & tune –beam profiles, beam current, luminosity Power converters –accept real-time trims RF –? Reference magnets –supply real-time measurements of bn Control –real-time site wide communication –centralised real-time computing facilities –control room interface, programming environment –synchronization –knobs

TC 25th October8 To be addressed Is this acceptable for all equipment groups concerned? Who’s responsible for what? –Front-ends - BI, PC, RF, MTA –field buses –gateways –network RT backbone –RT centralised computing, operator interface, alogorithms –maintenance –operational support When are we going to do what ? –prototyping: SPS, laboratory –sm-18, sector test, lhc commisioning ? How to proceed from here ? –working group? Milestones?