data-dictionary
data-dictionary
Breadcrumbs

FPSBASE.RTG_REF_QUEUE_MULTI_AREA_WIP

Data Dictionary

>

FPSBASE Views

> FPSBASE.WIP_WAFER_HIST_LOOP

View FPSBASE.RTG_REF_QUEUE_MULTI_AREA_WIP

This is checking if any step in the queue sequence already has too much WIP for us to want to start more lots into the timer. This logic only applies if the timer spreads over multiple sched_groups (counting not scheduled as a group) because Scheduler will handle if the timer is entirely within one sched_group. The logic here says that any lot which is already in a queue timer will need to run before the lots that we are considering whether or not we should start at the queue start step. In addition, we assume that lots without queue timers will run at their current step if not on hold unless they have been sitting for over seven days in which case we assume they will continue to sit. This logic is certainly not perfect but it is reasonable. For all lots that are at or coming to a step that is the start step for a timer over multiple sched groups, we use this logic for WIP ahead of this lot and only block the lot from starting if ALL of the following are true for one of the steps in the timer: 1) WIP per tool ahead of this lot by process family indicates that the lot cannot process before the queue timer will expire 2) WIP per tool ahead of this lot by process subfamily indicates that the lot cannot process before the queue timer will expire 3) Conservative subfamily logic assuming the subfamily only gets 50% of the tool capacity in the family that it used in the last week does not indicate that it can still make the timer. 4) Sched_start is after the queue timer will expire (or lot is not scheduled at the step) Consider #1 as the baseline logic and #2 and #3 and #4 as exceptions, #2 in one direction and #3+4 in the other direction, to cover cases where all tools in the family cannot run all processes. #2 covers the case where the process family overall has capacity but the specific tools that can run this subfamily are backed up. For this check, we assume that the subfamily could use all of the capacity of its allowed tools since we know the process family overall has capacity. In this case, we want to block the lot from starting. The opposite of this is #3 where the process family overall does not have capacity but the subfamily does. For this one we certainly cannot assume the subfamily can use all of the capacity of its allowed tools. It is tricky to even used the historical weighted capacity because we know the family overall is backed up and other subfamilies will likely take more of the capacity than normal. So we conservatively assume that the subfamily will be able to use 50% of the historical weighted capacity which will at least allow a few lots of each subfamily to trickle in to the timer. #4 also covers the similar case as #3 where the process family overall is over capacity but it is weighted towards other tools and the tools where this lot can run are able to run before the timer expires. This logic says if the Scheduler found a spot for the lot to run before the queue timer expires then far be it from this multi area queue logic which is not as smart as Scheduler to say that it cannot run. This is better than #3 but since Scheduler only schedule 12-24 hours in advance we still need #3 to cover queue timers which are longer than the schedule windows of 12-24 hours.

Column

Comment

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)

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)

START_NUM_STEPS_AWAY

IS_QUEUE_STOPPED

RN_FOR_LOT_ROUTE_STEP

RN_FOR_ROUTE_STEP

WAIT_SEC_TO_SCHED

The lot may be scheduled but must not be allowed to dispatch or start until this number of seconds has elapsed. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

WAIT_TO_SCHED_REASON

QUEUE_EXPLANATION

QUEUE_CALCULATION

QUEUE_CALC_SUBF_ALLOW

SCHED_GROUP_LIST

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)

ROUTE

Route that has threading requirements (* inherited from FPSINPUT.RTG_STEP_THREADING)

START_STEP

Start step that will impact the future thread step rank in RTG_TOOL_ASSIGNMENT_LOT (* inherited from FPSINPUT.RTG_STEP_THREADING)

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)

FEED_IF_LESS_THAN_SEC

If WIP in the queue sequence as measured by total seconds of EET is below this number then we should prioritize lots entering the sequence. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS)

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)

MIN_WAIT_SEC

All lots must wait at least this many seconds at the step before processing. This column is the opposite of the others and can only be populated if the others are null. Also start_step and end_step must be the same since this can only apply at a single step. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS)

PROCESS_FAMILY

See https://help.inficonims.com/display/DW/Guide+to+Process+Families. (* inherited from FPSINPUT.RTG_PROCESS_FAMILIES)

PROCESS_SUBFAMILY

Route step family is used for the Dashboard to separate processes in a process family based on shared but limited assignments. It is also the base for GP subfamily. (* inherited from FPSBASE.RTG_ROUTE_STEPS_PLUS)

NUM_TOOLS_UP

NUM_TOOLS_DOWN

NUM_TOOLS_UP_SUBF_ALLOW

NUM_TOOLS_DOWN_SUBF_ALLOW

UTIL_OF_AVAIL

AVG_UPH

AVG_SMP_RATE

QTY_IN_TIMER

QTY_CURR_STEP_PRTY

QTY_CURR_STEP

CUM_LOT_FOR_TIMER

USE_UP

HRS_BEF_Q

FREE_SEC_FOR_TIMER

HRS_BEF_Q_SUBF_ALLOW

FREE_SEC_FOR_TIMER_SUBF_ALLOW

SUBFAM_USED_OR_NULL

NON_TIMER_WIP_PCT

When calculating the time required to process WIP through a queue timer segment, we normally consider both WIP on queue timers, as well as non-queue-time-limited WIP in the same area, equally in terms of their impact on the available capacity of the tools required to run the segment. If this is set to <100%, then we under-weight the impact of the non-queue-time-limited WIP accordingly. We strongly recommend keeping it at 100%, because setting it to a low value can cause scheduler to prioritize excessive queue timer WIP, and delay running non-queue-time-limited WIP. (* inherited from FPSINPUT.RTG_QUEUE_TIMERS)