Log inRegister

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
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki Send feedback | Imprint | Privacy Policy (in German)
This website is using cookies. More info. That's Fine