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)

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:

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

(note the spaces)

Open

(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:

Open

No Plan

3.18+

You can insert a “NoPlan” state on the line level, if there is no order/changeover/cleaning present:

-3.17

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:

No Work Hours

3.18+

You can insert a “NoWorkHours” state on the line level, if there is no shift currently planned for the line:

You can also check in this rule if there is an ongoing order - and make the line switchto “NoWorkHours” only if there is no order in progress:

-3.17

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.

-3.17 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:

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: