ALERT! Warning: your browser isn't supported. Please install a modern one, like Firefox, Opera, Safari, Chrome or the latest Internet Explorer. Thank you!
Log inLog in to FAIR Wiki. | RegisterSign on to FAIR Wiki.

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
        • 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:
  • 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:

-- RalphSteinhagen - 19 Dec 2017
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding FAIR Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)
Syndicate this site RSS