Understand frequency type production unit count
- Last UpdatedOct 23, 2024
- 5 minute read
If a sample plan frequency is configured to generate future samples for a production count frequency—that is, the sample plan frequency type is Production—and the frequency is configured to count individual units, the active QM specification using this frequency generates future samples either to the end of the shift or the time specified in the future sample generation property. If the production count frequency is configured to count any setting other than units, then it behaves as an event trigger frequency and no future samples are generated. For samples to be generated for this frequency, a job must be running on the entity.
The job’s production rate is used to estimate the time when future samples will be generated. For example, a production unit count frequency of every 50 units in effect when a job with a production rate of 10 batches per hour and a batch size of 20 units per batch will create future samples 15 minutes apart.
50 units / (10 batches/hour * 20 units/batch) * 60 minutes / hour = 15 minutes
Samples will be predicted when the job starts on the entity and any remaining future samples will be deleted when the job stops. Future samples will be predicted to the end of the shift if there is no Future sample generation setting; otherwise, samples will be generated up to the "future sample generation" interval. In either case, samples will be predicted to cover only the starting quantity of the job plus one additional sample for over production. Using the above frequency example, if a job is started with a start quantity of 225 units, then 5 samples will be generated every 15 minutes apart. If the Future sample generation setting is 0, then no future sample are generated and the frequency behaves as an event frequency generating samples with the production of a sufficient quantity of units.
Unlike the calendar and shift frequencies, future production unit count samples are readied (moved to the sample table) only when the required number of units have been produced instead of based on the future sample request time. Both good and bad counts of production are considered when readying a sample. As production counts are recorded against the job, the total is maintained in a context table in the database. This includes when the production quantity is reduced. When a production transaction causes the total to equal or exceed the frequency interval units, then the next available future sample will be readied by the MES middleware maintenance service during the next update of sample status. This might take up to the time period specified by the system parameter Frequency to call sample updates (in seconds), which has a default of 30 seconds. Using the above example of a frequency with 50 units:
|
Time |
Production Units Reported |
Context Table Count |
Sample Generated |
|---|---|---|---|
|
10:03 |
10 |
10 |
No |
|
10:06 |
10 |
20 |
No |
|
10:09 |
10 |
30 |
No |
|
10:12 |
10 |
40 |
No |
|
10:15 |
10 |
0 |
Yes |
Once a sample is generated, it cannot be deleted through a reduction of production. In this case, the context table becomes negative and the following sample will be readied once the additional amount has been produced. A production transaction that amounts to a total count that exceeds the frequency interval, even if it exceeds it by a factor of 2 or more, will still only generate a single ready sample. Using the same example, a production transaction of 100 units will only generate a single ready sample, not two, and the excess multiple of the interval (50 in this case) will be ignored.
Prediction of the request time for the first sample may take into consideration production counts from previous jobs. The context of the active QM Specification is used to determine if any existing quantities in the context table should be used in predicting the initial requested time. In a simple case, the previous example of a job with 225 units is run and, at the completion of the job, there are 25 units remaining in the context table. Another job is started following the first for 225 more units using the same QM specification. The leftover 25 units will be used in the estimation of the first sample, so the first sample request time will be 7.5 minutes in the future instead of the normal 15 minutes since 25 of the required 50 units have already been produced by the previous job and are used in the estimation of this job. The usage of previous context information is configurable based on the Production Reset option in the production count frequency definition. The available Production Reset options choices are described below.
Never
Always use all applicable context records matching the context of the active QM Specification. In certain cases, this will be more than one record.
The job changes
When a new job is run on an entity, all applicable context records are set to 0.
Main item produced changes
All applicable context records are set to 0 if either of the follow occurs:
-
A new job is started on an entity that is producing a different item from the previous item run on the entity.
-
Production is reported against a substitute item for the same job.
Shift changes on entity
At the completion of a shift change, all applicable context records are set to 0. This will impact the sample request times for samples based on the current job.
If the quantity of all previous context records applicable to the context of a new job started on an entity is equal to or greater than the production count frequency interval, then the first predicted sample is based on the amount of time it will take to produce enough units to match the maximum setting for all the included characteristic’s minimum sample size.
As production is recorded, sample request times will be updated as part of the production transaction. However, if production is not recorded, then the MES middleware maintenance service will adjust sample request times based on the setting of the system parameter Sample wait time for delayed production (in minutes).
-
If this parameter is set to 0, then there are no adjustments to future sample request times and it is possible for a "future" request time to have a value in the past. When there are two future samples with a request time in the past, then the first one will be deleted by the MES middleware maintenance service.
-
If this parameter is set to a non-zero value, then when a future sample’s requested time is in the past, all sample_to_go records for the entity and for the production count frequency will have their requested times increased by the specified number of minutes. If this causes any samples to be pushed forward into the next shift and the Future sample generation setting is Null, those samples pushed into the next shift will be deleted.