Real-time

1
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.

2
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.

3
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.

4
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

5
RT requirements II
Response limited by PC/magnet
6
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

7
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

8
To be addressed

• Is this acceptable for all equipment groups
  concerned?
• Whos 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?