BSS Control

BSS Control is an application for monitoring and controlling the execution of patterns in the facility. The users can see and (in some cases) change the execution status of the patterns. It is in some ways similar to old "Pulszentrale" applications.

Available information (2019-02)

• Enabled by Operator state of Pattern Group (signal)
• Enabled by Operator state of Pattern (signal)
• Enabled by LSA state of Pattern (signal)
• Beam request state of beam destination associated with Pattern (signal)
• Enabled by MASP state of chain (MASP state)

Additional information planned for future releases

"Is pattern currently running?"

One way to determine this is looking at the events that are currently being played. There might be other possible ways, e.g. trying to retrieve that information from the generator/data master, but those ways would have to be discussed (how to access that information, possible additional overhead/latency for generator/data master for exposing that information, additional information needed to interpret that information, etc.).

AW: Clarify with Product Owner what information is actually needed, and if there might be other ways to display it. E.g. would a timestamp "last ran at xx:xx:xx" be sufficient? Also make sure to talk about the difference between chains and patterns, and that multiple chains in a pattern can be running at the same time! This is different from the old system, were machines were rectangles and were only ever played in sequence, never in parallel.

Determining which chain/pattern is running based on played events

This is not as trivial as it first appears.

• What does "running" mean?
  • "Events for the context are being played"? -> also shows that a context is running during (possibly long) beamout periods
  • "Beam-In events for the context are being played"?
• Identifying the correct chain/pattern:
  • Events only contain information about the beam processes and chains they belong to, not about the pattern. We therefore need additional (=not provided by the events) information about the resident patterns to find out which pattern a chain belongs to.
  • Events refer to the beam processes and chains with an index that is not identical to their LSA id, but instead allocated by LSA every time a pattern is made resident. Those indices are freed and can be reused when a pattern becomes non-resident. This means that in order to determine which chain is currently running, we need up-to-date information about the resident patterns. If a pattern A is made non-resident and a pattern B is made resident, B may reuse chain indices or beam process indices formerly used by A. If we work with outdated information, we may determine that (a chain in) A is running, when in truth (a chain in) B is running. [However, with our current Supply mechanism in the Scheduling app, it seems very unlikely that this will happen often.]
• Identifying the start of chains/patterns (as of 2019-02):
  • Patterns start with a GAP_END event for their first chain. As long as there is only one chain per pattern, we can use this event and GAP_START to determine which chain and, with additional information about the resident patterns, which pattern is running.
  • Chains start with SEQ_START.
  • Note: As any listener to events might start listening while a pattern is already being executed, just any event that is received for a chain/pattern (and that does not mark the end of the context) should be interpreted as the "start" of that context if the context is not already known to be running.
• Identifying the end of chains/patterns (as of 2019-02):
  • Patterns end with a GAP_START event for their last chain.
  • Things will be more complicated if we want information about which chain is running. Chains do not have a dedicated "chain end" event. If we use the context scheduling information of the resident patterns as additional information, we might be able to identify chain ends:
    • A chain C ends when a GAP_START for C is received.
    • For rectangular chains: A chain C_a ends when a SEQ_START or BP_START is received for a beam process belonging to a different Chain C_b from the same pattern.
    • For non-rectangular chains/parallelograms: A chain C_a ends when a SEQ_START or BP_START is received for a beam process (belonging to a different chain C_b from the same pattern) which directly follows the beam process(es) belonging to C_a with the highest end time.
      • Example: If the BP of C1 with the highest end timestamp is BP_x, then the start of the BP that is the direct successor of BP_x in the same Particle Transfer signals that C1 is over. There might be multiple "last" BPs of C1.
    • There might be chains which are always running unless the pattern ends: Their beam process with the latest end timestamp has a beam process belonging to itself as a successor (= there is no beam process belonging to another chain in the respective particle transfer).
      • Once we have "parallelogramm" chains, we might have a chain that starts over before it has reached its end - effectively, that means that it is "always running" as well. We would receive like [chain start], [chain start], [chain end],[chain start],[chain end],[chain end] and would have to be careful not to misinterpret those events . AW: Maybe the Beam Production Chain Time Stamp in the event could be helpful?
• Dealing with "lost" events (unclear if necessary?)
  • If we, for whatever reason, would "lose" all events that mark the end of a context's execution (e.g. because of a malfunction of the timing system or the Snoop FESA class that collects the events), we would still think that the context is running even though it isn't anymore.
    • Theoretically, we could use a timeout and assume that a context is not running anymore if we do not receive an event belonging to that context within a specified time period. However, this approach will produce false information in multiple circumstances:
      • There is no maximum distance between events in a pattern, so long gaps between events in regular patterns are allowed. In 2019-01, there were multiple patterns on dev and pro with gaps of 10-22 seconds (!) between events. => Contexts would be falsely considered to be not running if timeout is too short.
      • Patterns in Storage Ring mode may be waiting in wait loops e.g. for injection, on-the-fly manipulations, "stop points", etc. for an indeterminable time. There is no guarantee that events will be played during those wait loops. Therefore there might be phases of indeterminable length during which pattern execution is still "ongoing" (a part of the pattern has already been executed, and, once certain conditions are fulfilled, the rest of the pattern will be executed), but no events are received for the pattern. => Contexts would be falsely considered to be not running if timeout is too short. Because the time a pattern remains in this state is indeterminable, defining a useful timeout period is virtually impossible (if the timeout period is very long, a context for which events were truly lost would be considered still running for that very long time, which would also be false information).

"Is pattern currently ready to run?"

This is an aggregated status that is supposed to describe if there are currently and reasons preventing the pattern from being run or not.

The Director component of BSS internally uses this information, and it does not make much sense to re-implement that functionality. AW is planning to ask S. Krepp if this information can be made accessible for BSS Control in any way.

"One-time requests" / triggered execution of a context

A possibly problematic special case is the "one-time requests" (?) / triggered execution of a chain or pattern. The beam request information in BSS Control currently describes the "permanent request" for a beam destination. "One-time requests" are performed on the same beam destination specific signal as permanent requests, but with a special call to the Request Processor ("triggersignalstates" (one-time) vs. "updatesignalstates" (permanent)). As far as I (AW) know, when a "one-time request" is triggered on a signal, the RP/Director only evaluate that trigger internally and modify the schedule accordingly for a one-time execution of the pattern. The enabled state of the triggered signal is not changed, and I (AW) am not sure if the internal "ready" state for a chain/pattern changes. It's also important to note that even if the enabled state of the triggered signal would be changed for a short time and then reset, it would currently (2019-02) be possible that BSS Control misses that change because it only polls the signal state every few seconds.

This means for the UI that we would display a chain/pattern as NOT requested, therefore NOT ready to run - but it may still run once in a while when triggered by a "one-time request", without any way for us to detect or display that the pattern was, for a moment, "ready to run". This may appear inconsistent or wrong to the users.

UI overhaul in January 2019

Old

• very verbose
• takes up a lot of space -> often, only 2 of 3 pattern groups fit on the screen
• feedback from operators: important status information is hard to comprehend (needs reading, most prominent colour is the chain colour which does not describe status information)

New

• uses symbols instead of verbose descriptions -> similar to old "Pulszentrale"
• uses less space -> 3 pattern groups should fit on a screen
• chain colour is much less prominent, important status information is (hopefully) more prominent and concise

-- AnnekeWalter - 28 Jan 2019