FPSBASE.WIP_PRIORITIES_PLUS

PRIORITY

This is the priority value as it is stored in the MES for each lot. It might be a number or a letter or word depending on the MES and the facility. (* inherited from FPSINPUT.WIP_PRIORITIES)

PRIORITY_DISPLAY

The name of the priority displayed on all dashboards and reports. Typically priority is short like P1, P2 so we allow a longer more descriptive name here that should be more familiar to the users. (* inherited from FPSINPUT.WIP_PRIORITIES)

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)

DESCRIPTION

Tool desciption. This value is only used to display in the Dashboard. (* inherited from FPSINPUT.EQP_TOOLS)

IS_PLAN_PRIORITY

Flag indicates whether this priority is a plan_priority which is the permanent priority for the lot. If this is N that indicates this is a temporary priority such as queue time warning or SPC jeopardy. (* inherited from FPSINPUT.WIP_PRIORITIES)

IS_HIGHLIGHTED_PRTY

This flag indicates if this priority should be highlighted on the dashboard. When we sort all priorities by priority_sort all Y should be first followed by all N. (* inherited from FPSINPUT.WIP_PRIORITIES)

BG_COLOR

Background color assigned. BG_COLOR is in English like red or blue or light green and we look up the HTML color like #FF0000 in the GEN_COLORS table. BG_COLOR must be set manually but the FPSADMIN view BLD_POPULATE_COLORS will generate queries to randomly set bg_color for all values in a table. (* inherited from FPSINPUT.GEN_CUSTOMERS)

IS_COUNT_PRIORITY_PCT

This flag determines which priorities to include in our overall percentage of priority lots in the Dashboard spotlight. This is similar to is_highlighted_prty but it is possible that we might want to highlight a priority but not include it in the percentage. (* inherited from FPSINPUT.WIP_PRIORITIES)

HOLD_PRTY_GROUP

This field determines the grouping of hold lots displayed on the Dashboard hold page. Typically the highlighted priorities will each be in their own group and all others will be in a group named OTHERS. We might want to separate low priority lots too. (* 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)

PRTY_CTM_GROUP

This is one of the primary keys of our CTM tables. We use this group rather than the priority because we often have several different priorities which are close and are expected to have the same cycle time. (* inherited from FPSINPUT.WIP_PRIORITIES)

PRTY_CTM_FACTOR

Factor to multiply cycle time for this priority group compared to other groups if not known. For example, if this factor is 1.5 and we know the CTM is 6 hours for another priority group whose factor is 1.0 then we would estimate it to be 9 hours for this group. (* inherited from FPSINPUT.WIP_PRTY_CTM_GROUPS)

PRTY_TRANSPORT_MODE

Priority level transport mode. If no other mode is specified, this will be the value used to direct wip with a specific priority. (* inherited from FPSINPUT.WIP_PRIORITIES)

MAX_STEP_SEC_NOHOLD_FOR_WSF

Prevent huge cycle times at steps where a minority of lots have been waiting for an exceedingly long time (* inherited from FPSINPUT.WIP_PRTY_CTM_GROUPS)

MAX_HOLD_SEC_FOR_WSF

Prevent huge cycle times at steps where a minority of lots have been on hold for an exceedingly long time (* inherited from FPSINPUT.WIP_PRTY_CTM_GROUPS)

PROC_TIME_LOOK_AHEAD_PCT

For batching logic in the Scheduler, the percentage of the processing time that we will wait for future lots to arrive to make a full batch. For example, high priorities might have 0 for this column meaning we will never wait for future lots. Standard priority default is 100 meaning if the batch processing time is 2 hours that we would wait for up to 2 hours for future lots to arrive. Low priority might be 200 meaning we will wait up to 4 hours. Of course Scheduler might choose to process an incomplete batch sooner based on other logic but this is upper bound. (* inherited from FPSINPUT.WIP_PRIORITIES)

NEVER_STOP_FOR_QUEUE

Often we want to exempt all lots of certain high priorities from stopping due to excess WIP in a queue time sequence. (* inherited from FPSINPUT.WIP_PRIORITIES)

NEVER_WAIT_FOR_MIN_BATCH

For the very highest priority lots, we typically want to ignore any min_batch_size requirements and always run the lot immediately. If this flag is set to Y for a priority then lots of that priority will never wait to form a batch even if the tool and/or recipe has a min_batch_size specified by lots and/or carriers and/or units. Technically this flag forces rcp_min_batch_wait_mins to always be 0 in WIP_STEP_FUT_ASGN_xxx views. (* inherited from FPSINPUT.WIP_PRIORITIES)

IS_NMV_PRIORITY

This flag indicates if this priority should be emphasized in NextMove (* inherited from FPSINPUT.WIP_PRIORITIES)

IS_TIMER_WIP_PRIORITY

Flag inicates if this priority is excluded from multi area non queue timer wip percentage calculation. If this flag is set to Y, any non queue timer WIP of the priority will count as 100% in multi area queue timer logic. (* inherited from FPSINPUT.WIP_PRIORITIES)

MAX_CTM_XFACTOR

Maximum x-factor, which is a multiplier of raw process time, that cycle time will be allowed to be for predicting future step arrival times. For example, if the value is set to 1.5 for hot lots, then cycle time will be capped at 1.5 * process time for each step. (* 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)

USE_CTM_FACTOR_IF_OVR