Machine and Line States

A line is a set of interconnected machines expected to work smoothly together. As you might now, that’s rarely the case. There are often buffers between machines, designed to ‘compensate’ the stoppages of individual machines. As long as the downtime does not impact the base availability machine, it’s safe to say that the line as a whole keeps working. Yet, if such stoppage (e.g. from 'Labeller) propagates and stops the base availability machine - we say that the line is stopped because of the machine stopped (e.g. Labeller)

There are two 'levels' of state history for each line

• Machine level - where all stoppages of are registered, regardless of the impact on the line. They are mostly determined automatically by the state rules (https://ilabo.atlassian.net/wiki/spaces/LW/pages/1795424257) but also can be modified manually (more about that later). They can be reported independently and impact machine MTBF scores, maintenance rules in KeepUp and health score.

• Line level - where stoppages are determined through the root cause analysis, manual interventions or activity status (changeover/cleaning). You can also create rules on the line level the same way you do for the machine, PackOS will fallback to the root cause search process if none of the rules are true.

Let’s consider the following scenarios:

1. Line stopped explicitly in line-level state

The line was stopped manually by the operator using the ‘pause’ button, and by selecting a ‘forced’ state, or one of the line-level rules holds.

This is especially useful for line-wide activities like changeovers, cleaning, lunch breaks, maintenance, etc.

This scenario completely ignores machine states, they are often in some random failure (e.g. door open), machines might be restarted, alarms flashing etc. But none of that is reflected on the line level. No machine is selected as the ‘root cause’

Open

To set a line-level stoppage, use the ‘pause’ button in the main dashboard and select one of the forced downtimes.

Open

When changing an existing line downtime - make sure to select a line instead of one of the machines

2. Machine stopped, but not propagated to the line level

One of the machine failed, possibly even causing downtimes on other machines, but the stop has never reached the base availability machine.

Such ‘internal’ stoppages are very common. It’s still possible to add or modify such downtimes on individual machines (e.g. by opening a downtime list, or double-clicking a downtime on the work spectrum) but they won’t be reflected on the line level.

In this case, the labeller state is represented by two fields

• It’s own state - IDLE, which triggered the root cause search

• Reference to the root cause - failure on Capper
  
  

Let’s say the history looks like below:

There are multiple things you can do:

1. You can change the state of the machine itself by selecting the ‘Downtime’ tab.

2. You can select a different downtime type of the root cause. This will adjust Capper’s state from the Labeller perspective. (You will be able to see this change in Capper downtime list)

3. You can change the root cause machine, which was stopped around that time. Select it and adjust the downtime type:

4. You can select a machine which was not stopped around that time, and select a downtime.
This will create a new downtime on that machine, 1:1 corresponding to the initial stop.
(Note: Creating a downtime on base availability machine in this way does not create a line downtime)

3. Base availability stopped, without a root cause

Base machine stopped itself, no other machine is selected as a root cause

If line is not in a line-level downtime, all base availability stoppages are copied on the line-level. The downtime type, selected reason and corrective action - all are inherited by the line.

Note that now, the list of possible reasons and corrective actions refers to the definition of the failure on that root machine itself. Even though it’s being updated from the line’s perspective. To modify/add a reason or a corrective action in settings, you’ll need to find this downtime in the appropriate machine.

4. Base availability stopped, with a root cause

Base availability stopped, because one of the other machines was in downtime long enough. Buffers has been exhausted and the stop has propagated to the base machine.

The duration of the stop is still corresponds to the base availability machine, however to determine the state of the line, PackOS ‘follows the root cause’ - finds the machine which was the initial reason of the sequence of stoppages.

Root machine’s downtime type, with it’s set of possible reasons and corrective actions are now visible on the line log

Modifying stoppages from the line perspective will also impact machine downtime log. e.g. changing a type of downtime from ‘Failure’ to ‘Stop by operator’ will modify the stop on the machine itself.

Changing the root cause machine will follow the same algorithm as described in 2. updating, or adding a new downtime in the state history of the selected machine.

You can also change any of the stoppages to a line-level stop. Just select the line instead of the machine, and choose one of the states.

5. Line-level production threshold not exceeded

The setting End ongoing downtime, is set on line level to some non-zero value. Base availability stopped in ‘Failure X’, and then started. The line remains in ‘Failure X’ as long as the production threshold is not met

Note that the line counts production using the ‘base quantity’ machine. There might be a significant delay between the end of stoppage on base availability, and the first count. Still, it’s very often useful to capture this delay as ‘downtime', because it includes the machine warmup which may be significant.