Counting Production

To count yielded and wasted products, a machine needs to define a variable of type COUNTER for good products and many variables of type WASTE_COUNTER for wasted products.

PackOS is tracking the value of each counter and creating a history of counter Δ deltas verifying whether the counter increase should be accepted.

Open

Valid increase guard

There is a number of scenarios PackOS is considering in order to calculate the production volume

• Value is not processable because it’s not a number (e.g. ‘abcd’) - change ignored

• Value has not changed (e.g. 5 → 5) - change ignored

• Value has decreased (e.g. 5 → 2) - change ignored

• It’s the first received value ever (e.g. ? → 10) - change ignored

• There was a counter reset - the value went down to 0, then to a value lower than before 0
  (e.g. 1000 → 0 → 10: +10) - increase from 0 is checked with the performance

• There was a communication issue - the value went down to 0, then to a value a bit higher than before 0
  (e.g. 1000 → 0 → 1002: +2) - increase from the value before 0 is checked with the performance

Performance guard

Finally, if the change was not yet ignored, it’s checked against the expected designed performance of the machine.

If designed performance is not set (or set to 0), this guard is skipped. If the increase was not rejected at an earlier stage (see above) the increase is always accepted.

PackOS assumes that if the counter value is changing - it’s being published regularly. So to determine if the value is accepted the following variables are needed:

• Δt - time difference between the previous, and the current value

• Δy - difference between the observed values (counter increase)

• t_max - maximum acceptable delay between counter changes (max acceptable Δt when the counter is increasing constantly)

• p - designed performance - as products per second

The following predicate needs to hold in order for the counter to be accepted:

Which roughly translates to:

The time difference between the registered values is capped by the maximum acceptable counter delay. The counter increase is acceptable, if it’s smaller than the time difference multiplied by the machine’s designed performance.

This ensures that the counter is rejected in particular in the following scenarios:

• There is a very high counter increase, caused for instance by a bit flip or maintenance

• There was a long maintenance/cleaning activity on the machine, during which the counter was increasing but was not being reported. After the activity the last counter value was published and created an observable jump.

State guard

If the “Allow production on downtime” flag is not enabled, PackOS will reject any counters overlapping states other than work.

Note that this also applies to any downtimes added or removed in the future. Total production is recalculated accepting or ignoring the counts registered during the modified period of time.

If “Allow production on downtime” is enabled, all counter increases will be accepted, regardless of the downtime. Except for counts registered during downtimes with DiscardCounters tag

Line & Order production

To understand how machine-level production is being propagated to a line-level, take a look at the following diagram. Line production is always inherited from the base quantity machine, whereas line waste is a sum of waste from all machines.

Open

After passing Valid increase guard and Performance guard described above, the increase is separately checked against machine-level State guard, and separately goes higher up to a line level.

If the line has a different unit then the counter, the value is converted using an active packing structure
(read more https://ilabo.atlassian.net/wiki/spaces/LW/pages/1875968001). If the necessary unit conversion is not found - the increase is ignored.

Then, on the line-level, the increase needs to pass separately a State guard and a possible manual production adjustment before being accepted to a line-level production.

Finally, all accepted line-level production passes through a final unit conversion, which converts it to an order unit

Highlights:

• Machine-level state guard is independent of the line-level guard

  • If a different machine is a base ‘quantity' and different a base ‘availability’, the state of the line can be significantly desynchronised, so enabling “Allow production on downtime” is recommended

  • “Allow production on downtime” can be disabled on machine level, and separately enabled on line-level, but this is not recommended, as it may lead to confusing results (where the line produced more than the machine)

  • If “Allow production on downtime” is disabled on line-level, forcing/adding downtimes may lead to ignored counts which are not ignored on machine-level

• There is no separate performance guard for the line, so the designed performance of the base quantity machine plays a key role here

Count settlement

When closing an order, you can see a settlement of the production for a line.
The purpose of this view is to explain the production PackOS classify for the order

You can see, from the top:

• Base quantity raw counter

• How much was rejected on the machine, due to the performance guard

• How much was rejected due to a missing packing structure

• Line-level counter total on the line-level (after unit conversion)

• On which states, and how much counts has been ignored
  (Only when ‘Allow production on downtime’ is disabled)

• What was the impact of manual reconciliation

• What was the unit conversion between line and order

• What is a total volume for the order

You can see this summary, when closing an order, or for completed orders.

You can also view it for the line, by going to “Production” → “Summary”:

Or you can see it for an individual machine by clicking on it, and opening “Counters”: