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.
pencil_goRestoreRestore previous versiontext_align_leftRawView wiki markupeyeViewView formatted topictimeHistoryView revision historystart FirstView first revisionprev PreviousView previous revisionnext NextView next revisionend LastView last revisioncrossCloseClose this dialog

Difference: MachineInterlockStatus (2 vs. 3)

MachineInterlockStatus 3 - 19 Dec 2017 - Main.RalphSteinhagen
Line: 1 to 1
 
META TOPICPARENT name="FairControlTopics"
Changed:
<
<

High-Level Application Requirements for Machine Interlock Status

>
>

High-Level User Requirements for the Machine Interlock Status Application

 
Changed:
<
<
  • Status: draft (no edms link yet)
>
>
  • 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
Changed:
<
<
    • identification and localisation of faults, two primary displays as graphical and textual entry points:
      1. hierarchical tree-(table)- status-view with the specific raised interlock/system being highlighted/expanded
>
>
    • 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, ...
Changed:
<
<
      1. graphical machine synopsis with machine/transfer-line segments being highlighted where the interlock has been raised
>
>
      1. 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)
Line: 35 to 35
 
      • 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)
Deleted:
<
<
  • Secondary functional requirements: <expert diagnostics/features, etc.>
 
    • history of collective interlock status (ie. for how long/how often has the (global) interlock state been active)
Added:
>
>
  • Secondary functional requirements: <expert diagnostics/features, etc.>
 
    • display of all device statuses (even if nominally masked/suppressed for given BPC)
    • bridging/masking of interlocks
Line: 55 to 55
 
  • Known failure modes: <issues that need to be taken into account during initial design>
  • Typical/Common displays options:
    • 90% case (daily operation, monitoring)
Changed:
<
<
      • tree-table- status-view
>
>
      • tree-table-view
 
      • graphical machine synopsis
      • detailed status view
    • 10% case (expert, debugging, troubleshooting functionality)

Revision 03
Revision 12