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.

Basic statuses

The basic statuses are primarily represented by the background color.

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.png		Inspect detailed status. On-call duty depends on interlock type
1	Locally controlled	Tool (representing manual work)		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.png	No final decison on icon metaphor.	Probably FESA?
3	Turned off	Power off icon		detailed_status_off_white.png		Inside application
3	Stand-by	Standby icon		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		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.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		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.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.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.png	Status is mutually exclusive. An unknown status means that no other status information can be read.	Probably FESA?
	Not connected	Unplugged power cable		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
In beam	Beam-destroying	Beam-destroying	Position icon
In beam	Beam-influencing	Beam-influencing	Position icon
In beam	Not beam-influencing	Information	Position 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)

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		detailed_status_step_motor_inner_white.png
Moved somewhere between outer end position and 0.	Inbetween position		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		detailed_status_step_motor_outer_white.png
Position unknown	Position icon with question mark		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

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?

Links

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