Data Dictionary
>
FPSINPUT Views
> FPSINPUT.WIP_WAFER_HIST_LOOP
View FPSBASE.RTG_REF_QUEUE_MULTI_AREA_PRTY
This logic gives a curr_priority to lots in a queue timer if the X-Factor required to finish the timer before it expires is less than the threshold configured for that priority. For example, let's say QUEUE2x priority is configured to have a threshold of 2x processing time and QUEUE3x priority is configured at 3x. We have a lot which is 3 steps from the end of the queue timer and those three steps have 1, 2, and 2 hours of processing time, respectively. The queue timer will expire in 10 hours but all timers end when the lot begins processing at the end step. In order to calculate our X-Factor correctly, we need to add the 2 hours processing at the end step to the expire inst. So we get (10 + 2) / (1 + 2 + 2) = 12 / 5 = 2.4. This X-Factor Required of 2.4 is not less than the threshold for QUEUE2X so it does not get that highest priority but it is less than the threshold for QUEUE3X so it gets that priority. This priority of QUEUE3X is fed to the Dashboard for display and to the Scheduler for calculation and is used by all components of the DWH. The logic to calculate the xfactor_rqd is in RTG_QUEUE_MULTI_AREA_BASE but makes sense to comment about it here since this is the key to setting the curr_priority.
|
Column |
Comment |
|---|---|
|
LOT |
A lot is a group of units that process together. Usually lot_id or lot_number in MES. All units in a lot are in the same carrier but there may be multiple lots in a carrier. (* inherited from FPSINPUT.WIP_LOTS_STATIC) |
|
TIMER_ID |
Unique number representing the queue timer to index with other tables. Automatically populated with RTG_QUEUE_TIMERS_ID_SEQ sequence. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS) |
|
ROUTE_OF_END_STEP |
|
|
END_STEP |
The step upon move out where the WIP balance limit is no longer applied (* inherited from FPSINPUT.RTG_STEP_BALANCE) |
|
SEQ_NUM_OF_END_STEP |
|
|
QUEUE_PRIORITY |
|
|
PRIORITY_SORT |
Unique sort of priority. Sort ascending gives the order from highest to lowest priority. Therefore the smallest number in priority_sort is the highest priority. (* inherited from FPSINPUT.WIP_PRIORITIES) |
|
SCHED_SORT |
The sorting used by the scheduler to prioritize lots. This is more generic than priority_sort as different priorities may have the same sched_sort. (* inherited from FPSINPUT.WIP_PRIORITIES) |
|
TIMER_PRTY_XFACTOR |
This allows us to give a curr_priority value to lots in a queue timer if the X-Factor required to finish the timer before it expires is less than this threshold. For example, QUEUE2X priority is configured to have a threshold of 2x processing time and QUEUE3X priority is configured at 3x. We have a lot which is 3 steps from the end of the queue timer and those three steps have 1, 2, and 2 hours of processing time, respectively. The queue timer will expire in 20 hours but all timers end when the lot begins processing at the end step. In order to calculate our X-Factor we need to add the 3 hours processing at the end step. So we get (10 + 2) / (1 + 2 + 2) = 12 / 5 = 2.4. This X-Factor of 2.4 is not less than the threshold for QUEUE2X so it does not get that highest priority but it is less than the threshold for QUEUE3X so it gets that priority. This priority of QUEUE3X is fed to the Dashboard for display and to the Scheduler for calculation and is used by all components of the DWH. (* inherited from FPSINPUT.WIP_PRIORITIES) |
|
XFACTOR_RQD |
|
|
END_STEPS_AWAY |
|
|
QUEUE_START_INST |
|
|
EXPIRED_SEC |
Seconds from the start event until queue time restriction is expired. After expiration, the lot must rework or scrap or otherwise be evaluated. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS) |
|
EXPIRED_INST |
|
|
EXPIRED_INST_PLUS_TCT |
|
|
END_STEP_COMP_INST_IF_TCT |
|
|
RWK_IF_EXPIRED |
Indicates whether rework is required after queue timer expires. If allowed, we need to specify the route and step that we expect the lot to move into for rework. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS) |
|
START_STEP |
Start step that will impact the future thread step rank in RTG_TOOL_ASSIGNMENT_LOT (* inherited from FPSINPUT.RTG_STEP_THREADING) |
|
CURR_STEP |
|
|
FACILITY |
Facility is included in almost every join in the DWH so this represents a definitive split. A route must have all steps on tools in the same facility. A tool must process all lots in the same facility. If your site has multiple buildings where lots run on routes using tools in multiple buildings then everything should be one facility. For example, multiple Fab buildings. But if your site has independent facilities like Fab and Test and Assembly where lot may progress from one to the next but on different routes then these should be different facilities. Since this column is in virtually every table it is critical that the value here is exactly matches what is in the MES if the MES has facility. Use facility_display for the display friendly name displayed in applications. See site_name comment for client/site/facility example. (* inherited from FPSINPUT.GEN_FACILITIES) |
|
24 |
|
|
24 |
|
|
1 |
|
|
CURR_PRIORITY_REASON |
An optional description of why the priority is set as it is. This is typically shown as additional information on pages related to priority lots. (* inherited from FPSINPUT.WIP_LOTS_STATIC) |