Device status visualization

Guideline status

Draft

Problem description

Solution - centered on beam-influence of devices

The basic idea here is that the most important information is always the device's influence on the beam. This can have different reasons though. The device can be moved into the beamline for some reason or there is a device-related issue that affects normal beam operation. The different statuses are basically different severities defining how much the device affects the beam.

v13b_showcase.png

Basic statuses

The basic statuses are primarily represented by the background color.

colors_explanation_beam_influence.png

Color definitons:
  • Beam-destroying: 240, 66, 66 (#F04242)
  • Beam-influencing: 247, 159, 72 (#F79F48)
  • Information: 67, 128, 188 (#4380BC)
  • Not beam influencing: 67, 188, 88, (#43BC58)

Beam-destroying status: The highest rating problem is displayed for a device if it destroys the beam. This can be either the position of the device or its malfunctioning e.g. power off, offline, local and so on. In this status the operateur has to act to make operation working again.

Beam-influencing status: Use when a device is influencing the beam but not destroying it. The status should only be used when it’s guaranteed that the device's issue or position is not destroying the beam. This may also be influenced by the beam parameters which must be considered. In this status the operateur needs to check if the influence on the beam is intended or not.

Information status: This status means that there is no influence on the beam, but there is a non-critical device-related issue or the device is moved into the beamline without any expected impacts on the beam. It's important to display a detailed status in this case. In this status the operateur doesn't have to act immediately.

Not beam-influencing status (okay): This status means that the status of the device is fully okay. For those devices which can be moved into the beamline the status also means that its position won't influence the beam. The icon for the detailed status can be omitted when necessary to reduce clutter. In this case the operateur doesn't have to take action.

Detailed device statuses

Just like in the old concept, the color only communicates the basic status. The detailed status is represented by an icon. This can be one of the following.
Prio Detailed status name Visual idea Icon Preview Resource Comment Operator action / On-call duty
0 (Highest) Interlock Linked chains detailed_status_interlock_white_20px_v1.png detailed_status_interlock_white.png   Inspect detailed status. On-call duty depends on interlock type
1 Locally controlled Tool (representing manual work) local_white_20px_showcase.png detailed_status_local_white.png   Can the operator turn it back to remote by walking to the device? Probably equipment group?
2 Modules not ready

Could be

Modules or components representing a part of a larger system.

Hardware or chip.

detailed_status_modules_not_ready_white_20px_v6.png detailed_status_modules_not_ready_white.png No final decison on icon metaphor. Probably FESA?
3 Turned off Power off icon off_white_20px_(showcase).png detailed_status_off_white.png   Inside application
3 Stand-by Standby icon detailed_status_standby_white_v1.png detailed_status_standby_white.png Use when device is basically turned on, but associated HF is not. Inside application
3 Turned on, active Power on icon on_1.png detailed_status_on_white.png FESA devices don't support active and inactive. They are always displayed as turned on and active. Inside application
4 Turned on, unexpected inactive Man standing still detailed_status_inactive_white_v1.png detailed_status_inactive_white.png

No final decison on icon metaphor.

Use when a device access device is expected to be on and active, but is inactive. In the new control system there is no known mechanism for an expected setting. Devices controlled by the setting management system are all expected to be 'active' all the time. For these 'inactive' is all an unwanted status. For all other devices supporting 'active and 'inactive' there is no expected status.

Inside application (Sequencer)
4 Turned on, unexpected active Man running running_white_20px_(showcase).png detailed_status_active_white.png Use when a device access device is expected to be on and inactive, but is active. As devices controlled by the settings management system are always expected to be active, this status may no longer by relevant.  
5 Not op-ready General error detailed_status_error_white_20px_v1.png detailed_status_error_white.png When status is fine it means status is okay or warning, no interlock pending, remotely controlled and modules are ready. So when OP-ready is not true, this means the FESA developer has set op-ready to false for unknown reasons.
This status should be questioned as it is (or should be) just a sum of several statuses and can potentially used to add other stuff which is considered relevant for being op-ready.
Currently this status also covers Status=Error (consider when op-ready is removed).
Probably FESA?
7 Status warning General warning detailed_status_warning_white_v1.png detailed_status_warning_white.png Display when no other matches and status is set to 'Warning'. Currently the severity of this status is always 'Information'. See section 'open questions' for more details. Probably equipment group?
  Status unknown Question mark detailed_status_unknown_white_v1.png detailed_status_unknown_white.png Status is mutually exclusive. An unknown status means that no other status information can be read. Probably FESA?
  Not connected Unplugged power cable plugged_off_white_20px_(showcase).png detailed_status_not_connected_white.png Technically not really a status as no status can be read in this case. Status is mutually exclusive. Probably FESA?

Devices which can be moved into the beamline

Position Position severity Resulting primary status Detail icon
Not in beam Not beam-influencing Okay (Device status not okay -> Information) Position icon or no icon (device status icon when device status not okay)
Not in beam Beam-influencing Okay (Device status not okay -> Information) Position icon or no icon (device status icon when device status not okay)
Not in beam Beam-destroying Okay (Device status not okay -> Information) Position icon or no icon (device status icon when device status not okay)
In beam Not beam-influencing Information Position icon
In beam Beam-influencing Beam-influencing Position icon
In beam Beam-destroying Beam-destroying Position icon

Special icons may be added later for specific device types where a well known imagery exists.
Detailed status name Visual idea Icon Preview Resource Comment
Moved into beam (typically 0 position) Inner position step_motor_inner_white_20px_(showcase).png detailed_status_step_motor_inner_white.png  
Moved somewhere between outer end position and 0. Inbetween position step_motor_inbetween_white_20px_(showcase).png detailed_status_step_motor_inbetween_white.png Also display when between 0 and inner end position?
slit/actuator outer end position in beam reached Outer position step_motor_outer_white_20px_(showcase).png detailed_status_step_motor_outer_white.png  
Position unknown Position icon with question mark detailed_status_pos_unknown_white_v1.png detailed_status_step_motor_unknown_white.png  
Non-beam instrumentation devices are never displayed in a beam instrumentation overview. So even if they have beam-influencing statuses they never lead to the impression that a device status influences the beamline when looking a the beam instrumentation oveview from a greater distance.

It’s guaranteed that a device that can be moved into the beamline and has device issues, never influences the beam when it's not moved into the beamline.

Statuses when no context has been selected

Some statuses depend on context information. Without a context the severity of these statuses cannot be evaluated.
  • Don't display active/inactive information

Secondary status

As the primary status is set by the device's influence on the beamline, the secondary status is the complementary other state. So when the primary status is defined by the device's position, the secondary status is the actual device status.

As design variations have shown that an easily recognizable secondary status always competes with the primary status. When displaying the secondary status, it has to be displayed in an unobtrusive way, only recognizable when seitting in front of the display - if displayed at all. The benefit of the secondary status is limited to situations when there are both device-related issues and the device's position influences the beam. When a device is moved into the beamline for a longer time and the device has issues, this cannot be detected without a second status.

In the first iteration of this concept no secondary status is displayed.

Other status-relevant information

Power switching state
The old state is displayed while indicating that a new state is being set using an activity indicator.

RF turned off
The generators of an RF device are turned on but RF is turned off means the device is turned off in the end.

Mixed power statuses
When there is a device that combines several devices, the worst single status is displayed.

Visual representation

Text and icon colors

Always use white text.color and icons on top of colored areas. Depending on the space available the detailed status is displayed directly as overlay icon or in a tooltip.

Example of list item, detailed status displayed as overlay

List_item.PNG

Intended user interaction

The basic interaction is to see the basic status from a longer distance and see the detailed status when approaching the screen. When there is e.g. an interlock pending, the user has to get the interlock reason from somewhere else. This is not covered by this status representation.

Discussion

Pros

  • Consistently displays the same information in different contexts.
  • Could help to establish a status concept that works across applications as the influence on the beam is the key message.

Cons

  • Whenever the focus is on the device status itself it may be confusing to see the other beam-influencing reason: The device's position. This could be the case in the pictogram area for devices which can be moved into the beamline, where the user is mostly interested in the device's status.
  • As the severity of the device status for devices which can be moved into the beamline is always 'informational' it cannot be easily distinguished from a device which is moved into the beamline but has no influence on the beam. Both information display a different detailed status icon though.

Open questions

  • The question has arisen if some or all of the detailed statuses justify another basic status. An 'unknown' status would communicate that it's unknown if the beam will be influenced or even destroyed. This could be e.g. an unknown position of the device when moved into the beamline or the offline status where it's unknown
  • What about statuses that could lead to a beam-influencing or beam-destroying status later? Is it okay to handle them as informational or should there be an extra severity level (e.g. beam-influencing=yellow, (warning=orange)?
  • As certain magnets are set to zero current to control the beam, it must be asked if there are actually devices which are expected to be off at all. It must alos be considered that power is of course not an event setting, but ust a DC setting.
  • The severity of on/off is questionable when no context has been set. In almost all cases on is okay and off is beam-influencing or worse. One idea could be to reuse the old 'irrelevant' concept.
  • Some of the statuses itself must be discussed as they are currently not really helpful to operators. OP-ready and module-ready don't really help to take the proper actions.
  • Which of the statuses will lead to an interlock?
  • Should we distinguish between 'potentially beam-destroying' and 'certainly beam-destroying'?
  • How to handle drivetrain statuses? Combine with device status or separate?

Proposals for status colors (s.a. \\WinFilesvg\BEL$Root\belgroup\CS-Design\Specs-and-Requirements\5-Development-Guidelines\F-DG-C-02e_GUI-Guideline-v1.2.doc).

Implementation

Detailed status icons can be foiund in cscoap-common-images. They are called detailed_status_STATUSNAME_white.png.

Old and alternative concepts

Old and alternative concepts

Operator Summary

Operator Summary

Changes

15.08.18

  • Added 'unknown position' icon, updated the other position icons.

31.07.18

  • 1st iteration of new icons in section 'detialed device statuses' finished.

26.07.18

  • Reworked section 'Detailed device statuses'.

24.07.18

  • Added section 'Statuses when no context has been selected'
  • Remove Hardware from 'detailed device statuses'
  • Changes to 'open questions'

20.07.18

  • Set alternative 1 as new guideline. Moved old guidelines and alternatives to 'Old and alternative concepts' page.

17.07.18

  • Added new alternative concept (alternative 2) and more details to alternative 1.
  • Added new status concept to new chapter 'alternate concepts' (alternative 1)

09.05.18

  • Added colors for 'information' severity (used detailed status)

14.02.18

  • Fixed step motor statuses order

06.10.17

  • Addded section 'Example - beam-destroying devices'

18.05.17

  • Added 'known tradeoffs' section
  • Added truth tables for status display and some associated remarks.

08.09.16

  • Added resources for detailed status step motor icons (except actuator moving)

26.08.16

  • Updated icon previews to indicate that now black icon versions should be used
  • Updated section 'text and icon colors' (used black text always)
  • Added white status icons to SVN
  • Changed section to see more status-relevant information at once, new section 'visual representation' focuses on visual aspects
  • Removed detailed error status table column 'Expected' as it contained no vital information
  • New section 'detailed okay statuses'

25.08.16

  • Implementation section now informs about image location and names
  • Added white status icons to SVN
I Attachment Action Size Date WhoSorted descending Comment
List_item.PNGPNG List_item.PNG manage 4 K 17 Mar 2016 - 14:33 ChristianHillbricht  
Tooltip.PNGPNG Tooltip.PNG manage 1 K 12 Feb 2016 - 16:05 ChristianHillbricht  
active_1.pngpng active_1.png manage 1 K 18 May 2018 - 07:46 ChristianHillbricht Okay active
colors_explanation.PNGPNG colors_explanation.PNG manage 7 K 09 May 2018 - 15:58 ChristianHillbricht  
colors_explanation_beam_influence.pngpng colors_explanation_beam_influence.png manage 3 K 20 Jul 2018 - 12:52 ChristianHillbricht Color explanantion - focused on beam influence
detailed_status_error_white_20px_v1.pngpng detailed_status_error_white_20px_v1.png manage 1 K 30 Jul 2018 - 14:18 ChristianHillbricht error status
detailed_status_inactive_white_v1.pngpng detailed_status_inactive_white_v1.png manage 3 K 30 Jul 2018 - 13:56 ChristianHillbricht  
detailed_status_interlock_white_20px_v1.pngpng detailed_status_interlock_white_20px_v1.png manage 1 K 26 Jul 2018 - 08:21 ChristianHillbricht Interlock Icon Showcase
detailed_status_modules_not_ready_white_20px_v6.pngpng detailed_status_modules_not_ready_white_20px_v6.png manage 765 bytes 15 Nov 2018 - 12:15 ChristianHillbricht  
detailed_status_pos_unknown_white_v1.pngpng detailed_status_pos_unknown_white_v1.png manage 1 K 15 Aug 2018 - 12:32 ChristianHillbricht  
detailed_status_standby_white_v1.pngpng detailed_status_standby_white_v1.png manage 1 K 30 Jul 2018 - 14:29 ChristianHillbricht Standby Status
detailed_status_unknown_white_v1.pngpng detailed_status_unknown_white_v1.png manage 1 K 30 Jul 2018 - 13:40 ChristianHillbricht Unknown status
detailed_status_warning_white_v1.pngpng detailed_status_warning_white_v1.png manage 1 K 30 Jul 2018 - 14:20 ChristianHillbricht warning status
hardware_white_20px_(showcase).pngpng hardware_white_20px_(showcase).png manage 1 K 18 May 2018 - 07:28 ChristianHillbricht  
local_white_20px_showcase.pngpng local_white_20px_showcase.png manage 709 bytes 18 May 2018 - 07:29 ChristianHillbricht  
not_op-ready_white_20px_(showcase).pngpng not_op-ready_white_20px_(showcase).png manage 6 K 26 Aug 2016 - 13:08 ChristianHillbricht not op-ready white 20px (showcase)
not_ready_white_20px.pngpng not_ready_white_20px.png manage 1 K 18 May 2018 - 07:29 ChristianHillbricht  
off.pngpng off.png manage 903 bytes 18 May 2018 - 07:46 ChristianHillbricht Okay off black
off_white_20px_(showcase).pngpng off_white_20px_(showcase).png manage 827 bytes 18 May 2018 - 07:45 ChristianHillbricht  
on_1.pngpng on_1.png manage 313 bytes 18 May 2018 - 07:44 ChristianHillbricht Okay on
on_white_20px_(showcase).pngpng on_white_20px_(showcase).png manage 293 bytes 18 May 2018 - 07:45 ChristianHillbricht  
plugged_off_white_20px_(showcase).pngpng plugged_off_white_20px_(showcase).png manage 916 bytes 15 Nov 2018 - 14:08 ChristianHillbricht  
running_white_20px_(showcase).pngpng running_white_20px_(showcase).png manage 1 K 18 May 2018 - 07:34 ChristianHillbricht  
step_motor_inbetween_white_20px_(showcase).pngpng step_motor_inbetween_white_20px_(showcase).png manage 1 K 15 Aug 2018 - 12:38 ChristianHillbricht  
step_motor_inner_20px.pngpng step_motor_inner_20px.png manage 1 K 15 Aug 2018 - 12:38 ChristianHillbricht  
step_motor_inner_white_20px_(showcase).pngpng step_motor_inner_white_20px_(showcase).png manage 1 K 15 Aug 2018 - 12:38 ChristianHillbricht  
step_motor_outer_white_20px_(showcase).pngpng step_motor_outer_white_20px_(showcase).png manage 1 K 20 Aug 2018 - 14:29 ChristianHillbricht  
v12_showcase.pngpng v12_showcase.png manage 36 K 17 Jul 2018 - 09:29 ChristianHillbricht A2 v12 Showcase
v13b_showcase.pngpng v13b_showcase.png manage 39 K 17 Jul 2018 - 08:11 ChristianHillbricht v13b Showcase
Topic revision: r44 - 13 Apr 2020, JuttaFitzek
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 Foswiki? Send feedback