FPSAPP.RTG_SCHED_GROUPS

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)

SCHED_GROUP

VARCHAR2(36)

This is the grouping of tools and processes which the FPS Scheduler schedules together. Since this is a parent of tool via tool->process_group and a parent of process via process->process_group, by definition each tool and each process can only be in one sched group. We need all related tools and processes to be in the same sched group for efficient scheduling. One example is sinks and furnaces because of queue times and batching. Another example is for smaller facilities like Assembly or Test where we might schedule the entire facility together. (* from FPSINPUT.RTG_PROCESS_GROUPS)

ALERT_SEC

NUMBER(6)

This column is used to determine how long the SysMonitor (Health Check Alert Application) will wait (since last successful run) before issuing an alert and sending text message or email to the recipients.

AVG_CAL_SEC

NUMBER(6)

This is used to set how many seconds allowed to run the parallel calculation

CONFIG_ID

VARCHAR2(50)

This is used to tell which configuration the current sched-group is using

CURR_NUM_RUNS_FAIL

NUMBER(8)

WILL REMOVE SOON

CURR_NUM_RUNS_SUCCESS

NUMBER(8)

WILL REMOVE SOON

CURR_RUN_MODE

VARCHAR2(36)

WILL REMOVE SOON

DAYS_TO_KEEP_HIST

NUMBER(6,2)

This is used to determine how long to keep the historical data

DEFAULT_BAY

VARCHAR2(12)

for each sched group it will have default bay. this is really for the durable location issue

DEFAULT_NUM_RUNS_FAIL

NUMBER(4)

WILL REMOVE SOON

DEFAULT_NUM_RUNS_SUCCESS

NUMBER(4)

WILL REMOVE SOON

ENABLE_SENDING_ALERT

CHAR(1)

To indicate if the scheduler will send the alert while scheduler run failed. SYSMONITOR will only send the alert when SCHED_GROUP_STATE = OFF and ENABLE_SENDING_ALERT = Y

HOURS_TO_DISPLAY

NUMBER(5)

WILL REMOVE SOON

HOURS_TO_SCHEDULE

NUMBER(5)

This column is used to determine how many hours to look ahead and schedule the lots that might come into this area/SCHED-GROUP even it is still several steps away.

INT_SEC_TO_REFRESH_WEB_DATA

NUMBER(5)

Interval where Scheduler will refresh cached web data after this many seconds have elapsed since last refresh

INT_SEC_TO_RUN_SCHEDULER

NUMBER(5)

This column is used to determine how often to run the scheduler for this SCHED-GROUP. For example, if it sets 60 seconds in this column, it means it will wait for at least 60 seconds before initializing a new scheduler run from the end time of previous run.

IS_DEFAULT

CHAR(1)

This is used to land the first sched group on the scheduler/web by default

IS_DURABLE_SCHEDULED_ONLY

CHAR(1)

Check to see if trk views should only use scheduled durables

KEEP_FULL_LOTS_PER_LOOP

CHAR(1)

This flag determines if the Scheduler will add another lot to the loop after a lot is placed on the schedule in order to always keep the full number of lots in the loop. Having this flag on might slow down the calculation but is critical for tools with setup penalties and many different setups -- for example reticles on Litho cells. We will explain with a long example here. This full number of lots in the loop is determined by the configurable parameter NUM_LOTS_TO_SCHEDULE_PER_LOOP which has a default of 50. We always start by placing the processing and dispatched lots on the schedule and then picking the top 50*2=100 lots to go in the first loop based on the scores. These scores include setup based on the newest dispatched lot to each tool. The Scheduler does its looping algorithm on these 100 lots and places the most important lot on the schedule. We will say it was scheduled to tool T1 for example. If this flag in N then the Scheduler proceeds with its looping algorithm on the remaining 99 lots and places the next most important lot on the schedule -- and continues to do this 48 more times until it places 50 of the 100 lots in the first loop on the schedule. Then it calculates the scores for all remaining lots -- including the leftover 50 and all that did not make it in the first 100 -- and picks the next best 100. Then it does 50 loops to place lots 51 through 100 on the schedule. Then recalculates scores and continues until the full schedule is complete. The weak spot with this faster logic is that if lot #101 in the original loop is the same setup as the 49th lot placed on the schedule but none of the remaining 51 lots in the first loop match this setup that we will place one of these 51 lots next causing a setup change and then schedule lot #101 which had the same setup later. This would result in a particular tool having a schedule with setups A-A-B-B-A when we could have done A-A-A-B-B. That is where this flag helps. If this flag is Y then we still pick the top 100, do the looping algorithm, and place the first lot on the schedule to tool T1 as before. But then we recalculate the scores for the lots 101 and above which were not in the original loop -- but only for those lots allowed to T1 where we just placed a lot. Of all of these remaining lots we pick the top score and add to the 99 lots remaining from the first loop. This keeps 100 lots in the loop at all times! Scheduler does its looping algorithm and places a second lot on the schedule (for T2). Now it recalculates the scores for remaining lots that can run on T2 and adds the top lot to the loop. Note that if it did not find any lots allowed to T2 then it will add another lot to the loop so now we will have 99. This flag solves the same setup weakness described above because when the lot placed on the schedule is setup S1 then the next lot added to the loop would be another S1 lot if the scores determined that same setup was important enough to maintain.

MAX_CAL_SEC

NUMBER(6)

This is used to set how many seconds allowed to run the single-looping calculation. This includes all time taken for parallel calculation in AVG_CAL_SEC. As an example, if AVG_CAL_SEC is 300 and MAX_CAL_SEC is 360 then the first 300 seconds will be done with parallel calculation and the remaining 60 with serial/single-loop calculations. If scheduler takes more than this time to complete, it will be tagged as SLOW. This value should be greater than or equal to AVG_CAL_SEC. If equal to AVG_CAL_SEC, all calculations will be done via parallel calculations.

OTHER_NOTE

VARCHAR2(500)

Some description for this scheduler

RESCHED_MAX_CAP_SEC

NUMBER(6)

WILL REMOVE SOON

RESCHED_MIN_CAP_SEC

NUMBER(6)

How much better on sched-start-time on the lot to determine if it should break the current reservation to reschedule to another tool

SCHED_GROUP_DESC

VARCHAR2(256)

Longer description of sched_group

SCHED_GROUP_STATE

VARCHAR2(5)

State is constrained to one of three values. ON: Running for production. DEV: Schedule is visible for authorized users only (Q-Mgr and Scheduler run as if ON). OFF: Rarely used except when setting up a new sched_group.

SCH_IS_DE_RATE_LOT_AFT_RSV

CHAR(1)

To indicate if the scheduler will de-rate the lot score when it is outside of reservation window

SCH_IS_DE_RATE_TOOL_AFT_RSV

CHAR(1)

To indicate if the scheduler will de-rate the tool score when it is outside of reservation window

SHOULD_SCHEDULE_BLOCK_LOTS

CHAR(1)

WILL REMOVE SOON

SHOULD_SCHEDULE_HOLD_LOTS

CHAR(1)

This is used to indicate if the scheduler should schedule the hold lot or not

SHOULD_SHOW_SETUP_ON_LEGEND

CHAR(1)

To indicate if it is going to display the setup on the legends on the Scheduler/Web

SORT_ORDER

NUMBER(4)

This is used to sort within the grouping. SORT_ORDER always has a deferrable unique key to ensure uniqueness while allowing the user to make changes without erroring until the commit is attempted. Because of this you must be careful to not violate the unique key otherwise you will lose all of your edits. (* from FPSINPUT.GEN_FACILITIES)

STEPS_TO_SCHEDULE

NUMBER(5)

This column is used to determine how many steps to look ahead and schedule the lots that might come into this area/SCHED-GROUP even it is still several hours away. Between HOURS_TO_SCHEDULE and STEPS_TO_SCHEDULE, the Scheduler will try to schedule all the lots either will arrive within X hours OR within Y steps away.

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)

USE_MPCT_STATE_FOR_SCH

CHAR(1)

Flag to determine if Scheduler should use mpct state when determining UI color for main entities when ETP is enabled. When set to Y, the MPCT state will be used. When set to N, the ETP state will be used. When ETP is not enabled, this flag is not used.