High-Level User Requirements for the Machine Interlock Status Application

• Brief description : display and audiovisual alarms of beam inhibiting events and interlocks and first mitigation/system diagnostic procedures
• Background activity : GUI only
• Contact: AchimBlochSpaeth, JuttaFitzek, ChristianHillbricht, MaxMueller (developer), StephanReimann, ChristianSchmidt, PetraSchuett, JensStadlmann, RalphSteinhagen
• Priority: 1
• Status: draft (no EDMS link yet)
• Context:<reference to commissioning procedure, i.e. Phase A.1.2>
• Primary functional requirements: (N.B. top-level, user point-of-view)
  • coherent and concise presentation of accelerator facility/machine state (ie. interlocks & other events that may inhibit beam)
    • to note: medium- to long-term requirements of more comprehensive integration of all supporting sub-systems relevant to the accelerator operation
    • based on the initial discussion: accelerator and beam performance tracking/optimisation should be covered by a different application
  • identification and localisation of faults, two primary status displays as graphical and textual entry points:
    1. hierarchical tree-(table)-view with the specific raised interlock/system being highlighted/expanded (see right half of photo)
       • primary hierarchy: BeamProductionChain → machine → sub-system (ie. RF, power supplies, es. septa, cooling water, vacuum, ..) → device → failure pre-diagnostics/source within device/sub-system (e.g. water interlock, tracking error, …)
       • secondary hierarchy: sub-system → machine → device → failure pre-diagnostics/source within device/sub-system (for system experts)
       • OP masking of interlocks & unmasking of selected/all SBF- maskable device
         • SetupBeamFlag -maskable devices: e.g. BeamTransmissionMonitoring (BTM) system, BeamLossMonitors, most other beam-based measurement related inputs
       • filter on: BPC, machine, sub-system, device, masked devices, …
    2. graphical machine synopsis view with machine/transfer-line segments being highlighted where the interlock has been raised (see right half of photo)
       • small frame/panel containing the device→interlock source next to the physical location where the device is located (limit to top n-Interlocks)
       • expand/zoom-into machine/transfer-line view based on click on the component or interlock source
       • should display the BeamMode (String), SetupBeamFlag (dot), BeamPresenceFlag (dot) & BTM Transmission/Intensity Target Interlock status (dot, latter to be discussed)
       • OP masking of interlocks & unmasking of selected/all SBF- maskable device
       • a small Gant-type chart highlighting the BPC within the context of the larger scheduled TimingPattern
       • filter/click on BPC, machine, sub-system, device, …
  • detailed status view & execution of first-line self-aid procedures
    • presentation of detailed FESA 'Status' property information for selected device & BeamProductionChain
    • OP masking of interlocks & unmasking of selected/all SBF- maskable device
    • Button to manually trigger: Interlock/Device Reset (via FESA), Re-Init Device (via FESA), Power On/Off/Cycle (via FESA/SCU management), (more-)detailed device diagnostics & error-recovery procedure (via Sequencer)
  • audio-visual notification of OP crew/experimenters in case an interlock has been raised
    • should allow setting alarm for a given BeamProductionChain (beam inhibiting events)
    • should require acknowledgement/of alarm
    • feature: automatic alarm config reset at shift-start
  • visualisation of other information available through the MASP not explicitly mentioned above
    • MASP BPC inhibit matrix ('timing master inhibit' vs. 'beam mode' and SetupBeamFlag)
    • history of collective interlock status (ie. for how long/how often has the (global) interlock state been active)
• Secondary functional requirements: <expert diagnostics/features, etc.>
  • display of all device statuses (even if nominally masked/suppressed for given BPC)
  • bridging/masking of interlocks
    • SetupBeamFlag maskable interlocks → Operator
    • bridging of nominally faulty devices → machine/system expert
• External functional dependencies:
  
  • MachineStatusProcessor & InterlockSystem
  • GenericFESA /DeviceAccess Status property access
• Performance requirements:
  • should support update rates in the order of at least 1 Hz
  • should not block display on user interactions
• Safety/Reliability/Security requirements:
  
  • prior to the introduction of a RoleBasedAccess system, provisions should be made that the self-aid procedures are not executed by non-operational accounts
    • proposal for 2018: limit to OP console and developer user + OP directive
  • masking of nominally masked and faulty devices should be limited to machine and/or system experts
    • proposal for 2018: simple popup-style query + OP directive
• Known failure modes: <issues that need to be taken into account during initial design>
• Typical/Common displays options:
  • 90% case (daily operation, monitoring)
    • tree-table-view
    • graphical machine synopsis
    • detailed status view
  • 10% case (expert, debugging, troubleshooting functionality)
    • OP masking of interlocks & unmasking of selected/all SBF- maskable device
    • invocation of (more-)detailed device diagnostics and error-recovery procedures (via Sequencer)
• Acceptance Criteria:
  • optimisation goals:
    • minimise the required number of clicks/user interactions until the problem has been identified and resolved
    • focus on the display of faulty systems and re-group functional/"OK" devices to larger contexts as much as possible
      • simplicity is key: GUI and dependencies should be understood without being an OP/system expert
      • ie. zoom and dedicated 80% display area to the 1-5% fault cases
• Other comments ideas:
  • focus on interlocks defined as events that prevent beam from being produced, accelerated, and propagated through the BeamProductionChain (see also: wikipedia article)
  • graphical machine synopsis should be encapsulated as a widget so that it can be re-used as a dedicated fixed-display on one of the wall-displays
• References:
  • 2017-12-08 machine status display workshop #1 Use-Case OP, Use-Case MC & Equip. Groups, Use-Case User/Management/Experiment
  • 2017-12-08 machine status display workshop #2 Photo present operation → Photo Future operation