FPSADMIN.SCH_P_CFG_SCHED_GROUPS

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)

SCHED_GROUP

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

PRE_GROUP_INPUT_ID

CONFIG_ID

This is used to tell which configuration the current sched-group is using (* inherited from FPSINPUT.RTG_SCHED_GROUPS)

CONFIG_DESC

IS_CURR

Boolean flag where Y indicates this row is for the current main route or product. Same as flush_seq_num = 1. (* inherited from FPSBASE.WIP_FLUSH)

IS_ACTIVE

Flag to enable or disable the tag condition. (* inherited from FPSBASE.MSO_TAG_CONDITIONS)

CONFIG_SEQ_NUM

HOURS_TO_SCHEDULE

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

HOURS_TO_SCHEDULE_FIRST_STEP

to set the max hours to sched for the first step of each lot (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

HOURS_TO_SCHEDULE_TOOL_EVENT

to indicate how far in the future to include a tool_event. Any event that starts within current time + this value will be considered (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

HOURS_TO_SCHEDULE_MIN_BATCH

STEPS_TO_SCHEDULE

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

HOURS_TO_DISPLAY

WILL REMOVE SOON (* inherited from FPSINPUT.RTG_SCHED_GROUPS)

DAYS_TO_KEEP_HIST

This is used to determine how long to keep the historical data (* inherited from FPSINPUT.RTG_SCHED_GROUPS)

NUM_LOTS_TO_SCHEDULE_PER_LOOP

KEEP_FULL_LOTS_PER_LOOP

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

AVG_CAL_SEC

This is used to set how many seconds allowed to run the parallel calculation (* inherited from FPSINPUT.RTG_SCHED_GROUPS)

MAX_CAL_SEC

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

CREATE_INST

OTHER_NOTE

Some description for this scheduler (* inherited from FPSINPUT.RTG_SCHED_GROUPS)

SCH_IS_DE_RATE_LOT_AFT_RSV

To indicate if the scheduler will de-rate the lot score when it is outside of reservation window (* inherited from FPSINPUT.RTG_SCHED_GROUPS)

SCH_IS_DE_RATE_TOOL_AFT_RSV

To indicate if the scheduler will de-rate the tool score when it is outside of reservation window (* inherited from FPSINPUT.RTG_SCHED_GROUPS)

CONFIG_BY

DISPATCH_RULES

used to define the order of dispatching: 0. timer lots, the timer lot at least needs to be nearby and in-danger 1. lot on tool; durable on tool 2. lot on tool; durable near tool (on tool or stocker) 3. lot near tool; durable on tool 4. lot near tool; durable near tool 5. lot on tool; 6. lot near tool; 7. sched-rank-1 lot, currently at the operation; 8. enable dispatch based on lot priority; for example, (1):(3):(2):(4) -> will dispatch 1 first and followed by 3 and then 2 and then 4; for example, (1):(2|3):(4) -> will dispatch 1 first and followed by (2 or 3) and then 4; (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

BATCH_SIZE_WEIGHTS_CURRENT

the batch weights for the current batched lots (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

BATCH_SIZE_WEIGHTS_FUTURE

the batch weights for the lots will arrive before process starting (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

BATCH_SIZE_WEIGHTS_COMING

the batch weights for the lots will arrive after the process starting (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

BATCH_SIZE_WEIGHTS_FULL

the batch score bonus points for scheduling a full batch - either max size or all lots in scheduler window (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

BATCH_SIZE_WEIGHTS_AT_OPER

the batch score weight applied to the percent of lots that are at the batching operation (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

EXPIRED_QUEUE_TIMER_WEIGHT

how much weight to give lots with expired timers for example: A weight of 0 -> expired timers will all get the same score of 20. for example: A weight of 1 -> expired timers will get an additional point for every hour they are late (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

RSV_WEIGHTS_ON_NEXT_RQD_STEP

to assign the points to the next required step if the current step is reserved/dispatched (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

USE_MPCT_STATE

USE_NEXT_STEP_LOC_ON_TIMER

to indicate if it needs to use the location from the next step as primary location for the current step, for the timer lot (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

USE_NEXT_STEP_LOC_ON_LINK_STEP

to indicate if it needs to use the location from the next step as primary location for the current step, for the link step (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

STEP_ENTER_LOGISTIC_MIDPOINT

The midpoint of the S-curve function for step enter time. After this many hours, the raw sore will equal 5 for the function. (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

STEP_ENTER_LOGISTIC_SLOPE

The steepness of the S-curve function for step enter time. Larger numbers mean steeper curves - i.e. closer to a step function change. (* inherited from FPSAPP.SCH_C_GROUP_LOT_PRIORITIES)

MIN_EST_SMP_PCT_TO_SCHED

FEEDBACK_EMAIL

TIMER_TIME_SCHED_PCT

is used to determine how conservative the timer should be in schedulder (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

TIMER_HURRY_IN_HOURS

is used to determine when x hours left on the timer, the scheduler should start to prioritize the lot (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

TIMER_HURRY_IN_PCT

is used to determine when x % left on the timer, the scheduler should start to prioritize the lot (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

SCORING_TIME_BASE

the scoring time base is used to allow scheduler to calculate the time related points based on HOUR or DAY (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

WEIGHT_FOR_KIT_TIME_POINTS

WEIGHT_FOR_POD_SELECTION

WEIGHT_FOR_NUM_DURABLES_KITTED

WEIGHT_FOR_FIRST_DISP_INST

WEIGHT_FOR_SAME_POD

ALERT_SEC

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

SHOULD_UPDATE_WSFS

When this value is set to N, the scheduler will not write lot schedule results back to WIP_STEP_FUTURE_SCHED. Results will only be written to the snapshot tables (e.g. SCH_W_H_S_LOTS). This can be useful during an initial deployment of a new scheduler where you do not want the results from a scheduler to impact step enter times for other schedules (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

SHOULD_SCHEDULE_FUTURE_STARTS

When set to N, the scheduler will not include future WIP from WIP_STARTS in the scheduler. (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

RQD_PCT_TO_UPDATE_WSFS

When less than this percentage of lot steps are evaluated/placed before timeout, the scheduler will not update WIP_STEP_FUTURE_SCHED data for the run. Note that this is not the percent of scheduled lots - only the percent evaluated. If this parameter is set to 70 and in a run all lot/steps are evaluated by 31 percent cannot be scheduled (due to tool assignment or other), then the scheduler will still update WIP_STEP_FUTURE_SCHED. This flag is primarily to prevent SLOW scheduler runs from clearing WIP_STEP_FUTURE_SCHED. (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

NUM_TOP_TOOL_ASGNS_TO_EVL

to indicate the number of top tool assignments will be evaluated in the scheduler on the SCHED-GROUP. Default to 999, it means it will most likely to evaluate on every tool assignment (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

SHOW_CARRIER_ID

to set the visibility of a carrier id within a lot block in the Gantt chart. SHOW: Show the carrier id. HIDE: Hide the carrier id. SHOW_IF_DIFFERENT: Only show the carrier if it is different from the lot id (* inherited from FPSAPP.SCH_C_CFG_SCHED_GROUPS)

TIMER_CRITICAL_FACTOR