data-dictionary

FPSADMIN.WIP_PRIORITIES

Data Dictionary

>

FPSADMIN Tables

> FPSADMIN.WIP_PRIORITIES

Table FPSADMIN.WIP_PRIORITIES"

This table lists the possible set of priorities that can be assigned to lots in the facility with several columns used to properly configure Dashboard, Scheduler, and NextMove for each priority. If we were starting from scratch then we might have many of these columns in WIP_PRTY_CTM_GROUPS rather than WIP_PRIORITIES because it makes little sense to have two priorities in the same prty_ctm_group with different values for hold_prty_group, is_count_priority_pct, is_nmv_priority, is_timer_wip_priority, never_stop_for_queue, proc_time_look_ahead_pct, prty_transport_mode, sched_sort, and timer_prty_xfactor. Having said that, our ETL and our Scheduler views reference these columns in WIP_PRIORITIES so we will keep them in this table. When you are populating the ETL, please keep in mind that while you are technically allowed to have different values for priorities in the same prty_ctm_group that you likely want to keep them the same.

  • Schema: FPSADMIN

  • Tablespace: FPSDATA


Column

Type

Nullable

Comment

PRIORITY

VARCHAR2(7)

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.

BG_COLOR

VARCHAR2(24)

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. (* from FPSINPUT.GEN_CUSTOMERS)

DESCRIPTION

VARCHAR2(256)

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

HOLD_PRTY_GROUP

VARCHAR2(20)

N

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.

IS_COUNT_PRIORITY_PCT

CHAR(1)

N

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.

IS_HIGHLIGHTED_PRTY

CHAR(1)

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.

IS_NMV_PRIORITY

CHAR(1)

This flag indicates if this priority should be emphasized in NextMove

IS_PLAN_PRIORITY

CHAR(1)

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.

IS_TIMER_WIP_PRIORITY

CHAR(1)

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.

MAX_CTM_XFACTOR

NUMBER(5,2)

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.

NEVER_STOP_FOR_QUEUE

CHAR(1)

Often we want to exempt all lots of certain high priorities from stopping due to excess WIP in a queue time sequence.

NEVER_WAIT_FOR_MIN_BATCH

CHAR(1)

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.

PRIORITY_DISPLAY

VARCHAR2(20)

N

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.

PRIORITY_SORT

NUMBER(3)

N

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.

PROC_TIME_LOOK_AHEAD_PCT

NUMBER(3)

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.

PRTY_CTM_GROUP

VARCHAR2(7)

N

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.

PRTY_TRANSPORT_MODE

VARCHAR2(10)

Priority level transport mode. If no other mode is specified, this will be the value used to direct wip with a specific priority.

SCHED_SORT

NUMBER(3)

N

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.

TIMER_PRTY_XFACTOR

NUMBER(2,1)

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.