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.
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 performanceThere 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 ofthe 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:
Code Block |
---|
Îy < 2 * p * MIN(t_max, Ît) |
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.
Info |
---|
Before comparison, performance is translated to the counter unit. If the necessary packing structure needed to convert units is not defined - the performance will default to 0, and always accept the increase |
State guard
If the âAllow production on downtimeâ flag is not enabled, by default 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.
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 Unit Conversions). 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â: