Line state vs Schedule

Line-level state is mainly reflecting the state of the main machine. However, there are some line-wide activities which should impact reporting and in some sense ‘Ignore’ what’s happening on the main machine

Changeover

You can set a line-level state rule to start an appropriate line-level changeover, depending on:

  • Whether it’s running

  • Whether it’s delayed (expected time exceeded)

Make sure that this state does not have a ‘Forced’ flag
(Read more: https://ilabo.atlassian.net/wiki/spaces/LW/pages/1741783048)

This allows you to cover scenarios like:

  • If any changeover is delayed, the time outside of expected time should classify as availability loss

Configuring changeover state

To update line state based on the changeover status, you need to create a signal with the Source Uri:

line_{LineName}_active_changeover_execution_status

e.g. if the line name is Line With Filler the Source Uri will look the following:

line_Line With Filler_active_changeover_execution_status

(note the spaces)

(Keep the “Device ID” empty)

This signal will automatically provide the following values, depending on the changeover state on the line:

  • 0 - if no changeover is running

  • 1 - if there is changeover, but it's planned duration has not been exceeded

  • 2 - if the running changeover has exceeded it’s planned duration

You can incorporate this statuses in any rules you like, but the simplest configuration assigns a line-level ‘changeover' downtime, when the value of the signal is > 0, or separate states for 1 and 2:

 

Future improvements:
You will be able to set a changeover type, and take into account the type of the changeover in the line-level rule

This will allow you to cover scenarios like:

  • Changeover of type ‘A' classify as availability loss, and type 'B’ classify as utilisation loss

No Plan

After an order is completed. PackOS looks for a downtime marked with a NoPlan tag. This can be a downtime in any of the states (usually an ‘Inactive’ state).

The selected downtime will be started on line-level. It can have any of the other tags influencing the OEE impact, to adjust reporting of this period. Read more:

This state should have a ‘Forced’ flag. Otherwise, it will be overwritten from a machine-level state just after it starts. States with tag ‘Forced’
(Read more: https://ilabo.atlassian.net/wiki/spaces/LW/pages/1741783048)

No Work Hours

If there is no shift planned in the calendar, instead of immediately setting ‘No Plan’ state after order ends (like described above), PackOS looks for a downtime marked with a NoWorkHours tag.

This can be a downtime in any of the states (usually an ‘Inactive’ state). The selected downtime will be started on line-level. It can have any of the other tags influencing the OEE impact (can be different then NoPlan), to adjust reporting of this period.

This state should have a ‘Forced’ flag. Otherwise, it will be overwritten from a machine-level state just after it starts. States with tag ‘Forced’
(Read more: https://ilabo.atlassian.net/wiki/spaces/LW/pages/1741783048)

Relation with orders:
Orders by default has higher priority than ‘NoPlan’ or ‘NoWorkHours’ states. If the shift is overrunning the expected time, and there is still an order running, PackOS won’t enforce ‘NoWorkHours’ state.
If the order is expected to be continued the next day, the operator must manually enforce line-level breakdown at the end of day.

You can change this behaviour using the ENFORCE_OUTSIDE_WORKING_HOURS flag set as a plant property.
When set to ‘true’, downtime selected as “NoWorkHours” will begin regardless of the running order. If the order is overrunning outside the shift time someone will need to manually “start” the line

 

Cleaning

You can set a line-level state rule to start an appropriate line-level cleaning, depending on whether it’s running

Configuring cleaning state

To update line state based on the cleanming status, you need to create a signal with the Source Uri:

line_{LineName}_active_cleaning_execution_status

e.g. if the line name is Line With Filler the Source Uri will look the following:

(note the spaces)

 

(Keep the “Device ID” empty)

This signal will automatically provide the following values, depending on the cleaning state on the line:

  • 0 - if no cleaning is running

  • 1 - if there is cleaning

You can incorporate this statuses in any rules you like, but the simplest configuration assigns a line-level ‘cleaning' downtime, when the value of the signal is = 1, like in the example below: