FPSADMIN.RTG_QUEUE_TIMERS

FACILITY

VARCHAR2(6)

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

ROUTE

VARCHAR2(256)

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

START_STEP

VARCHAR2(256)

This is the step where the timer starts. See comments on the timer_start_event column for which event at this step starts the timer.

END_STEP

VARCHAR2(256)

This is the step where the timer ends. For minimum wait timers, this must be equal to the start_step. For single step timers, by definition this is the next step on the route after the start_step. For multi-step timers, this will be a step on the route after the start_step which is not the next step. Please note that we cannot set the end_step equal to the start_step for single step timers. Technically we do not treat single step timers any different than multi-step timers.

DESCRIPTION

VARCHAR2(256)

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

END_ROUTE_IF_DIFF

VARCHAR2(256)

Most normal queue timers start and end on the same route and for these we leave this column blank. However some timers start on a rework route and ending on the main route so this column allows us to support this. We would populate the route column with the rework route (the start step would be on this rework route) and this end_route_if_diff column with the main route (the end step would be on this main route).

EXCLUDE_HOLD_LOTS_IN_TIMER

CHAR(1)

This configuration will exclude any HOLD lots from queue timer consideration if set to Y.

EXPIRED_PULL_SEC

NUMBER(7)

EXPIRED_SEC

NUMBER(7)

Seconds from the start event until queue time restriction is expired. After expiration, the lot must rework or scrap or otherwise be evaluated.

FEED_IF_LESS_THAN_SEC

NUMBER(6)

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.

HIDE_TIMER_IN_DASH

CHAR(1)

This configuration will remove WIP for this timer_id from the Dashboard Queue Timer report.

MIN_WAIT_SEC

NUMBER(7)

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.

NON_TIMER_WIP_PCT

NUMBER(3)

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.

OVR_IS_QUEUE_STOPPED

CHAR(1)

This is Y if we know from the customer logic that lots cannot start the first step in the queue because their logic has determined that there is too much WIP already in the queue sequence. In the future, we will also use our own logic for this so we stop lots if this is Y or if our logic says to stop. In both cases, we can allow specific lots to go through using ovr_is_queue_allowed in WIP_LOTS_STATIC.

RWK_IF_EXPIRED

CHAR(1)

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.

RWK_ROUTE

VARCHAR2(256)

If the queue timer is from a rework route to the main route then this is the name of the rework route and the route column is the name of the main route.

RWK_START_STEP

VARCHAR2(256)

If the queue timer moves to a rework route and step from the main route then this is the start step on the rework route. The timer handling is treated the same once it enters rework, with the rework step starting the timer like the normal start step.

SCH_IGNORE_ON_EXPIRY

CHAR(1)

THE FLAG WHICH INDICATES TO STOP SCHEDULING UPON EXPIRATION OF THE TIMER

SCH_IGNORE_TIMER

CHAR(1)

When set to Y, this timer will not be loaded into the scheduler for consideration.

SCH_RESET_SCORE_ON_EXPIRY

CHAR(1)

THE FLAG WHICH INDICATES QUEUE TIMER SCORE SHOULD BE SET TO ZERO UPON EXPIRATION OF THE TIMER

SCH_WEIGHT_PER_HOUR_ON_EXPIRY

NUMBER(7,2)

THE VALUE WHICH INDICATES THE POINTS PER HOUR ADDED TO THE TIMER SCORE UPON EXPIRATION OF THE TIMER

TIMER_DISPLAY

VARCHAR2(48)

This column can be displyed on the Dashboard for the lot popup and lot search pages and is a shorter display field than the queue timer.

TIMER_END_EVENT

VARCHAR2(12)

The WIP event type which ends the queue timer at the end step. Prior to Scheduler version 1.18.1, the only choice is BEGIN so all timers will end when the lot starts processing at the end step. For 1.18.1+, DISPATCH, BEGIN, END, and COMP are all available options. Please note that scheduling timers that end on COMP and END events is much more difficult, as many factors can introduce significant variability to the processing time of a lot. DISPATCH and BEGIN are the preferred event types to use here.

TIMER_ID

NUMBER(9)

N

Unique number representing the queue timer to index with other tables. Automatically populated with RTG_QUEUE_TIMERS_ID_SEQ sequence.

TIMER_START_EVENT

VARCHAR2(12)

The WIP event type which starts the queue timer at the start step. The default and preferred choice is END since most timers should start when the lot ends processing at the start step but other choices are DISPATCH, BEGIN, and COMP. These four choices are a subset of list in WIP_EVENT_TYPES. This column would be more accurately named TIMER_START_EVENT_TYPE but this is in use everywhere and changing ETL makes upgrades significantly more difficult so we are leaving this slightly confusing column name.

UPDATED_INST

DATE

Time when the record was updated according to the source data. Note this is not the time when the record was actually updated in this table - it will almost always be earlier. (* from FPSINPUT.GEN_FACILITIES)

WAIT_SEC_TO_SCHED

NUMBER(7)

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

WAIT_SEC_UPDATED_INST

DATE

Time which may be used to adjust wait_sec_to_sched, usually based on how long a timer was been stopped. (* from FPSINPUT.WIP_LOTS_STATIC)

WARN_SEC

NUMBER(7)

Seconds from the start event until warning limit for queue time restriction. Lots that remain in the timer sequence longer than this warning limit should be prioritized to prevent them from expiring.