Configuring Downtimes¶

In this section of the configuration you can apply global settings related to Downtimes, including microstops and downtime justification. The user interface is as shown below:

The following actions are possible:

• Enable/disable microstops
• Set the color for microstops
• Set the microstop threshold
• Specify whether a microstop belongs to Availability loss or Performance loss
• Enable/disable downtime justification
• Enable/disable downtime justification strict mode
• Specify the rule to determine the downtime reasons that can be selected to overwrite a downtime.

Details of the configuration concepts are provided in the following sub-sections.

Microstops¶

Microstops are short downtimes that do not require any significant measures to get the machine back to the running state. They are typically so quick that it is not worth it for the operator to record their actions. However, when added together, they can contribute to significant loss of production time. Therefore, it is important to monitor them. As the definition of microstop varies for different use cases, in Insights Hub OEE, it is possible to configure your own preferences.

Microstops are often considered a Performance loss, but can also be an Availability loss depending on the user preference. In Insights Hub OEE, the user can make this decision, which will then be reflected in the resulting KPIs calculated in the analysis section. You can set a minimum duration for microstops, in seconds or minutes, below which a downtime would be categorized as a microstop. You can also select a color for microstops that will be used in the various charts in the analysis section.

If microstops are enabled, then downtimes less than the threshold time are categorized as microstops, and the number of microstops and microstop duration are reported separately. You can also see the microstop losses on the loss overview page as either Availability or Performance loss. If microstops are disabled, then downtimes are reported as a single category only.

Downtime Justification¶

Downtime justification means that you can enforce when an operator needs to select a different downtime reason than the default coming from the machine. If downtime justification is enabled, then you can specify which downtime reasons in the reason tree need to be justified. These are referred to as "weak" reasons: they do not sufficiently explain why a machine is in downtime.

The operator can see which downtimes have weak reasons in the Downtime Management view. Then, to justify the downtime, the operator must edit the downtime by changing the weak reason to a strong reason. A strong reason is any reason that is not defined as weak. There are toggle buttons in the reason tree configuration to specify which reasons are weak or strong (see Configuring reason trees). If downtime justification is not enabled, then this configuration option is not available in the reason trees.

If Downtime justification is enabled, then there is the option of applying "strict" mode. If strict mode is not enabled, then downtimes previously overwritten by a user with a weak reason will not show as needing to be justified. If strict is enabled, then downtimes with weak reasons will always show as needing to be justified, even if it has been selected by a human operator.

Downtime Selection¶

The "Overwrite downtime" selection determines which reasons are available for an operator to select when editing a downtime reason in the Downtime Management view. When downtime justification is not enabled, there is the option of showing "All reasons" or just "Subtree reasons only". If, instead, Downtime justification is enabled, then there are the further two options: "Strong reasons only" or "Strong subtree reasons only", with the strong reasons being defined in the reason tree.