FPSBASE.WIP_STEP_FUT_ASGN_FILTERED

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)

TOOL

Tool is generally just the main tool. The exception is when different entities on the tool run completely independently and it is physically impossible to run wafers of the same lot across multiple entities. In this exception case, we may want to assign the entities to different eqp_types and therefore we should define each entity as a tool. Please note that when we do this there is no indication whatsoever that these different entities are on the same tool. (* inherited from FPSINPUT.EQP_TOOLS)

CH_PATH

A path of chambers which can be used to process the lot on this tool. This is a concatenation of the single character CH from EQP_CHAMBERS similar to CH_ALLOWED. It is desired to list the chambers in order if there is an order however currently the order is not necessary and not used by Scheduler. (* inherited from FPSINPUT.RTG_TOOL_ASGN_LOT_RS_PATH)

NUM_STEPS_AWAY

Number of steps away not including steps which we know will be skipped nor those which we estimate will be skipped at least x pct of the time. This x value is configurable in GEN_FACILITIES using the smp_pct_for_num_steps_away column. (* inherited from FPSBASE.WIP_STEP_FUTURE)

STEP

A single processing step within a route representing a single tool visit. Step is often a very complex string and should rarely be displayed. Instead we should use process_display. (* inherited from FPSINPUT.RTG_ROUTE_STEPS)

ROUTE

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

PROCESS

Process defines what occurs at a step. Different steps can share the same process if they are identical. Process should normally determine allowed tools and recipe although it can be overridden by step, route, prd, lot, and experiment for exceptions. Each process is dynamically assigned to one or more eqp_type-process_family combinations with use_pct. One process_family is determined to be primary. If grouping is done correctly, a process should only be one eqp_group with no crossover. (* inherited from FPSINPUT.RTG_PROCESSES)

PRD

Prd determines the route which is used to process the lot in the facility and what tools, recipes, durables, etc. can be used at each step. Prd also determines the next facility for the lot when it finishes its route. For detailed information on prd vs. planprd see table comments in RTG_PLANPRDS. (* inherited from FPSINPUT.RTG_PRDS)

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)

IS_BY_LOT

SOURCE_ASGN_TABLE

SOURCE_ASGN_TAB_SORT

PERM_RANK

Permanent rank is typically loaded by ETL from a combination of the MES, recipe management system, and existing preference logic already used at the site. Possible values are in FPSADMIN.RTG_PERM_RANKS. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

TEMP_RANK

Temporary rank should only be set manually by a human user, never loaded automatically by ETL. Possible values are in FPSADMIN.RTG_PERM_RANKS. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

EXTL_RANK

Allowed values are P, F, W. For details on all EXTL columns please see Help Site page at https://help.finalphasesystems.com/display/SCHED/Scheduler+and+External+Model+Status. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

EST_MACHINE_RECIPE

Estimated machine recipe what we estimate will be the machine recipe based on information from the Recipe Management System. It is used in combination with process for throughput calculations and setup change penalty calculations. It is not necessary to estimate for all processes since this is always used in combination however it needs to be NA rather than blank since it is part of the primary key of most THP tables. Hopefully when this is not NA it should match the actual machine recipe logged for each lot during processing. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

LOGICAL_RECIPE

Used for infomational purpose and is populated if known otherwise it will match the recipe. (* inherited from FPSINPUT.WIP_EVENT_HIST)

STEP_ORDER

The order in which the steps will be visited. Note that this is not the sequence number on the route. It is only for sorting within this table. This information may be used to determine upcoming sampling decision or deviations from standard routing. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

IS_DURABLE_RQD

The scenario addressed here is when the recipe which requires a durable is allowed but the durable assignment is missing. We do not want to schedule lots without the durable but we could do this unless this flag is set to Y. Here are the four combinations for reference. 1) When is_durable_required is set to Y and there is a durable assigned then the Scheduler will schedule the lot using that durable. This is the normal Photo case. 2) When is_durable_required is set to Y and there is no durable assigned then the Scheduler will not allow the lot to be scheduled. This is important for Photo to not schedule without durable. 3) When is_durable_required is set to N and there is a durable assigned then the Scheduler will schedule the lot using that durable. You will notice that the flag actually does not matter when there is a durable assigned. That is this flag is not populated at some older sites so we cannot only look for the durable if this flag is set because then the Photo Scheduler would not schedule anything at these older sites. When is_durable_required is set to N and there is no durable assigned then the Scheduler will schedule the lot without a durable. This is the normal case for all groups outside of Photo. This would also be the case at the older sites for Photo except that we have some hardcoded logic at those sites to address this. Eventually we will transition all sites to use the is_durable_required flag. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

BATCH_CRITERIA

Lots that can run on the same batch TOOL and have the same value of BATCH_CRITERIA can run together in a batch. Therefore this is a critical column for scheduling on batch tools. If BATCH_CRITERIA is not populated, Scheduler defaults to the assumption that any WIP with the same EST_MACHINE_RECIPE can be batched together. Keep in mind that many MESs have additional constraints on batching (for example, that all WIP in a batch has the same SCRIPT_ID) and these must be incorporated into BATCH_CRITERIA to ensure that the batches are allowed by the MES. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

ZONES_ALLOWED

CH_ALLOWED

List of chambers allowed using the single character CH from EQP_CHAMBERS. While the concepts of cap_entity (capacity entity) and ch_type are important to our logic we agreed that there is no RMS or EI or MES on the planet that understands these concepts. All of these systems go by tool and chambers allowed and therefore our input tables must do the same. We list all chambers that can run and then calculate subsets of these chambers based on CH_TYPE. If all chambers are the same type then we assume you can run on any one or more of the chambers allowed. If the chambers are different types then we assume that at least one chamber of each type is required to run. If you populate either RTG_TOOL_ASGN_LOT_xxx_PATH table then you can leave ch_allowed blank since it will not be used. However there is nothing wrong with populating ch_allowed as a backup plan. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

IS_EXCLUSIVE_CHAMBER

This indicates that the tool may not run other jobs on other standby chambers while this job is running. For example, a process uses only chamber B on a three chamber tool. Normally that means you can run another job that uses A and/or C. However when this job is running you cannot run anything on chamber A nor C. If A and/or C are down you can still run the process on B. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

REQUIRE_ALL_CHAMBERS

This indicates that all chambers specified in CH_ALLOWED must be used. Normally we only require one chamber of each chamber type and can run with fewer chambers and a degraded throughput but not when this flag is set. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

CH_ASGN_RULES

String with complicated syntax indicating which chambers can be used by the Scheduler. For example, (A|B|C) means the lot can only run on chamber A or B or C but not all of chambers. For example, if it runs on A then no wafer from the same lot can run on B nor C. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

OVR_CH_PATH_RANK

This assignment rank is on the chamber path level and will override the tool assignment rank if populated. If null, the scheduler will use the tool assignment rank (* inherited from FPSINPUT.RTG_TOOL_ASGN_LOT_RS_PATH)

OVR_EST_MACHINE_RECIPE

When we use this path table then this value overrides the est_machine_recipe specified in the RTG_TOOL_ASSIGNMENTS_LOT or RTG_TOOL_ASGN_LOT_PROCESS table. It is common for the tool to use a different machine recipe for each different run path because the chambers are often listed in the recipe. But it is perfectly fine for the tool to use the same machine recipe for all run paths since we calculate THP separately for each ch_type_cnt. We require this column to be populated even when it is the same as in the RTA_LOT table to avoid having to join the tables even time we use the PATH table. (* inherited from FPSINPUT.RTG_TOOL_ASGN_LOT_RS_PATH)

OVR_SCHED_WEIGHTS

This is how much weight to give the chamber path rank. When populated, this will override the weights for chamber path rank and tool assignment rank. If null, then Scheduler will take the value from the configuration table SCH_C_GROUP_PERM_RANKS. example 1: ovr_sched_weights is 40 -> the chamber path rank will have a weight of 40, regardless of what ovr_ch_path_rank is. example 2: ovr_sched_weights is null and ovr_ch_path_rank == "A" -> the chamber path rank will get the weight for "A" from SCH_C_GROUP_PERM_RANKS example 3: ovr_sched_weights is null and ovr_ch_path_rank is null-> the chamber path rank will use the tool assignment rank and get the weight from SCH_C_GROUP_PERM_RANKS (* inherited from FPSINPUT.RTG_TOOL_ASGN_LOT_RS_PATH)

OVR_SCHED_WEIGHTS_BY_TOOL

This is how much weight to give the tool assignment rank. When populated, this will override the weights for tool assignment. If null, then Scheduler will take the value from the configuration table SCH_C_GROUP_PERM_RANKS. Note that ovr_sched_weight is also in the PATHS table so you can override either by tool or by chamber path. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

EXPT_ID

Experiment identifier which indicates the lot will process differently that normal for its product on at least one step of the route. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

EXPT_VARIATION

Assigned to sibling lots to indicate which variation of the experiment will be performed on the lot. For example, variation 0 might get the normal recipe while variation 1 might get a different recipe then we can compare the different wafers in each split at a following measurement or test step. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

IS_EXPT_STEP

Flag set to Y if the experiment requires abnormal processing at this step. (* inherited from FPSBASE.WIP_LOT_HIST)

RQD_QUAL_EVENT_ID

Used when a recipe requires a certain qual in order to be allowed to run. Often multiple recipes will require the same qual. One example is in Litho where several recipes all require a certain track monitor to pass in order to be allowed to run. When the qual has not passed (either failed or expired) then the curr_rank will automatically be set to Q which indicates the recipe is permanently allowed but not currently qualified. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

RQD_PORT_GROUP

Optional value if tool has different groups of ports, for example 150mm and 200mm. This indicates what is required for each lot and PORT_GROUP in EQP_PORTS indicates what ports can run this group. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

IS_NONSTD

Our column to indicate non-standard processing at the step. For example, an experiment or a chain that is only active at a particular step or set of steps and then goes back to being normal for the route. If an experiment is severe enough that it affects the final product and has to be planned separately then it will be its own prd or planprd. (* inherited from FPSBASE.WIP_LOT_HIST)

ASGN_PARM1

Four user-defined fields which can store anything the user would like to track relating to the assignment. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

ASGN_PARM2

See ASGN_PARM1. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

ASGN_PARM3

See ASGN_PARM1. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

PERM_RANK_USER

User or system who last updated permanent rank (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

PERM_RANK_UPDATED_INST

Datetime populated by trigger when permanent rank was last updated (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

PERM_RANK_COMMENT

Optional comment entered by user or system who last updated permanent rank (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

EXTL_RANK_USER

User or system who last updated external information. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

EXTL_RANK_UPDATED_INST

Datetime populated by trigger when external rank was last updated. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

EXTL_MODEL_EXPIRE_INST

Datetime when the model state will expire. This value is critical for prioritizing lots in Scheduler using the Expiring status. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

IS_EXTL_RANK_RENEWABLE

This flag indicates that if we run a lot applying to this record on the tool that we can renew the expiration of this rank. For example, a thread that expires after 48 hours of not being used. In this case, we would want to encourage scheduling a lot to renew the rank even if it is slightly lower priority than other lots. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

EXTL_ID

The identifier for the external model. For details on all EXTL columns please see Help Site page at https://help.finalphasesystems.com/display/SCHED/Scheduler+and+External+Model+Status. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

EXTL_STATUS_DISPLAY

Normally just a display field for the External Model status but if the value matches one of the allowed Model States then it is considered to be the Model State. For the list of Model States and full detailed on all EXTL columns please see Help Site page at https://help.finalphasesystems.com/display/SCHED/Scheduler+and+External+Model+Status. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

EXTL_RANK_COMMENT

Optional comment entered by user or system who last updated external information. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

TEMP_RANK_USER

User or system who last updated temporary rank (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

TEMP_RANK_UPDATED_INST

Datetime populated by trigger when external rank was last updated (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

TEMP_RANK_EXPIRE_INST

Optional column allows user to specify when the temporary rank expires. After this time we will use the permanent rank. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

TEMP_RANK_COMMENT

Optional comment entered by user or system who last updated temporary rank (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

ASGN_SCHED_SCORE1

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE1_COMMENT

This column should explain the score for ASGN_SCHED_SCORE1. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE2

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE2_COMMENT

This column should explain the score for ASGN_SCHED_SCORE2. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE3

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE3_COMMENT

This column should explain the score for ASGN_SCHED_SCORE3. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE4

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE4_COMMENT

This column should explain the score for ASGN_SCHED_SCORE4. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE5

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE5_COMMENT

This column should explain the score for ASGN_SCHED_SCORE5. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE6

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE6_COMMENT

This column should explain the score for ASGN_SCHED_SCORE6. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE7

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE7_COMMENT

This column should explain the score for ASGN_SCHED_SCORE7. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

BADGE_COLOR

This column is to indicate the badge color related to visibility on scheduler ganntchart, and the value should be corresponding to COLOR column in table GEN_COLORS (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

BALANCED_BATCH_TYPE

This parameter tells the scheduler whether and how the batch balance logic should be applied. Null means the logic is turned off. MATCH means that all lots in the balance group/pair must have unit quantities within this range. PREFER means that the scheduler should try to meet the criteria for MATCH, but if it cannot be met to add the next best lots to make a fuller batch. The maximum batch size for the process context must also be 4 lots/carriers if this value is not null. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

BALANCED_BATCH_QTY

When configured for balanced batching, this represents the maximum delta in unit quantity for lots to be considered balanced. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

SCH_CUSTOM_SETUP_MSG

Allow users to define a custom message to display on top of a lot box. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

CURR_PRIORITY

The priority at the current step. As the lot moves along the route after LAST_STEP_CURR_PRTY it will revert to PLAN_PRIORITY. For example, timelink or sendahead priority is only temporary. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

CURR_PRIORITY_REASON

An optional description of why the priority is set as it is. This is typically shown as additional information on pages related to priority lots. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

CURR_PRIORITY_DISPLAY

CURR_PRIORITY_SORT

IS_IN_PRTY_GANTT

NUM_STEPS_TO_RETURN

LINE_YIELD_PCT_TO_ARRV

EST_QTY_AT_ARRV

This column degrades the current qty by the estimated line yield at steps between the current step and future step so this represents the expected qty of the lot when it arrives to the future step. This is unlikely to be different than the current qty in a Fab but is quite important for Test/Sort/Assembly. (* inherited from FPSBASE.WIP_STEP_FUTURE)

CURR_COMP_TO_EARLIEST_ARRV_SEC

The comment on CURR_COMP_TO_EXPECTED_ARRV_SEC applies here too. The only difference is that this column is what we consider the earliest possible arrival rather than the expected arrival. (* inherited from FPSBASE.WIP_STEP_FUTURE)

CURR_COMP_TO_EXPECTED_ARRV_SEC

We use this numeric field rather than the date field EXPECTED_ARRV_INST but the date field depends on the estimated complete of the current step which depends on the current time. Therefore in order for EXPECTED_ARRV_INST to be accurate we would have to change it every second! Instead we use this field to store the seconds from the complete of the current step to the arrival which only needs to be updated when the lot changes steps. Then we do the calculations to get EXPECTED_ARRV_INST using the current time in the WIP_STEP_FUTURE_PLUS view. For all steps which are one step away, this value is always 0 which makes sense because the complete of the current step is the same as the arrival of the next step. (* inherited from FPSBASE.WIP_STEP_FUTURE)

CURR_COMP_TO_EARLIEST_COMP_SEC

CURR_COMP_TO_EXPECTED_COMP_SEC

FIRST_FUT_HOLD_STEP

FIRST_FUT_HOLD_NUM_STEPS_AWAY

FIRST_FUT_HOLD_NOTE

FUT_HOLD_SEC_TO_ARRV

FUT_HOLD_SEC_AT_STEP

FUT_HOLD_TYPE_AT_STEP

FUT_HOLD_NOTE_AT_STEP

EST_SMP_PCT

Smp_pct tells you what percentage of the lots complete on a tool. Some sites skip steps by jumping over them so we see the lot move from step 3 to step 5 and we only know that it jumped step 4 because step 4 is on the route between 3 and 5. Other sites skip steps by moving lots into them and then moving them out a second later so we see a move from 3 to 4 at 11:11:11 and a move from 4 to 5 at 11:11:12. We do not care how it is done but just that the lot did not process at step 4 -- and to be more specific that no tool capacity is required to process this lot at step 4 and no cycle time is accumulated at step 4. (* inherited from FPSBASE.WIP_GOAL_LOT_SHIFT)

PROCESS_FAMILY

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

PROCESS_GROUP

Process group is the critical field where tools and processes come together for the purposes of Scheduler. Process group is in both EQP_TOOLS for the tools and in RTG_PROCESSES for processes. Ideally all tools that run the same set of processes with no crossover including back-up and emergency tools would be in the same process group but it is important to note that this is not technically required for Scheduler as long as all process groups are in the same sched group. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

SEQ_NUM

Sequence number of step in route (* inherited from FPSINPUT.RTG_ROUTE_STEPS)

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)

IS_IN_NMV_PICK_LIST

Set to Y if lot-step is within range to be displayed in NextMove Pick List according to hours/steps_to_schedule fields in GEN_FACILITIES (* inherited from FPSBASE.WIP_STEP_FUTURE)

IS_START

Boolean flag where Y indicates the lot is an upcoming start and not an existing lot. (* inherited from FPSBASE.WIP_FLUSH)

IS_BANK

TIMER_ID_START_STEP

This indicates that this step is the start of a queue timer. Inner join with RTG_QUEUE_TIMERS using timer_id as there is no foreign key because the timer_id record might get deleted from RTG_QUEUE_TIMERS. (* inherited from FPSBASE.WIP_STEP_FUTURE)

TIMER_ID_MID_STEP

This indicates that this step is the end of a queue timer. Inner join with RTG_QUEUE_TIMERS using timer_id as there is no foreign key because the timer_id record might get deleted from RTG_QUEUE_TIMERS. (* inherited from FPSBASE.WIP_STEP_FUTURE)

TIMER_ID_END_STEP

This indicates that this step is in the middle of a queue timer. Inner join with RTG_QUEUE_TIMERS using timer_id as there is no foreign key because the timer_id record might get deleted from RTG_QUEUE_TIMERS. (* inherited from FPSBASE.WIP_STEP_FUTURE)

GOAL_BEGIN_INST

Time when the lot has to complete the current step to remain on schedule. (* inherited from FPSBASE.WIP_STEP_HIST)

GOAL_COMP_INST

GOAL_COMMENT

WAIT_SEC_TO_SCHED_QUEUE

WAIT_TO_SCHED_REASON_QUEUE

NEVER_STOP_FOR_QUEUE

Often we want to exempt all lots of certain high priorities from stopping due to excess WIP in a queue time sequence. (* inherited from FPSINPUT.WIP_PRIORITIES)

IS_STAGING_STEP

We expect large amounts of WIP and long cycle times at staging steps. We still calculate cycle time like any other step but the important difference is that lots currently at a staging step are not counted as normal coming lots to future steps. Instead we show them in a special column labeled From Staging. (* inherited from FPSINPUT.RTG_ROUTE_STEPS)

MIN_SETUP_SEC_FOR_RANK_S

Sometimes we actually have zero setup penalty for certain combinations in EQP_SETUP_CHG_MANUAL and we want to ignore these when we set the rank to S which leads to the ETP state of Standby With Setup Rqd. That will happen which both min_setup_sec_for_rank_s and min_setup_cost_for_rank_s are set to the default values of 0. But we might also want to ignore setups with a tiny albeit nonzero penalty which we can do by setting one or both of these columns to a tiny value greater than zero. Our rank logic will only count the setup change if the setup_sec is more than min_setup_sec_for_rank_s or the setup_cost is more than min_setup_cost_for_rank_s. (* inherited from FPSINPUT.GEN_FACILITIES)

MIN_SETUP_COST_FOR_RANK_S

See comment on MIN_SETUP_SEC_FOR_RANK_S. (* inherited from FPSINPUT.GEN_FACILITIES)

LOT_TYPE

Lot_type is the base of the hierarchy that determines lot_family then lot_group. Ideally lot_type will come straight from the MES with little modification. (* inherited from FPSINPUT.WIP_LOT_TYPES)

PLAN_PRIORITY

Permanent priority of the lot set in the MES generally by planning. (* inherited from FPSINPUT.WIP_EVENT_HIST)

PLAN_PRIORITY_DISPLAY

PLAN_PRIORITY_SORT

WAIT_SEC_TO_SCHED_STATIC

WAIT_TO_SCHED_REASON_STATIC

OVR_PROC_TIME_SEC

Override processing time for this lot at this step from the normal value calculated by THP_EQPTYPE_AUTO. Setting this value also forces a TAKE decision for this step in WIP_STEP_FUTURE. (* inherited from FPSINPUT.WIP_STEP_FUTURE_OVR)

ALL_CH_ON_TOOL

EQP_TYPE

Each tool is assigned an EQP_TYPE and all tools in the same type are identical meaning that they should run at the same throughput when running the same process with the same chamber type count. We also expect similar availability since these tools are identical. However tools in the same EQP_TYPE may have different chamber configurations and may run different groups of processes. (* inherited from FPSINPUT.EQP_TYPES)

SCHED_GROUP_OF_TOOL

SINGLE_CH_TYPE

When a tool only has one chamber then we do not include the chamber in EQP_CHAMBERS, however, for purposes of our throughput calculations we need to log the correct ch_type so that jobs can be accurately compared to other tools of the same eqp_type and ch_type. For example, if we have ET101 with one etch chamber A and ET102 with two etch chambers A and B then we estimate that a job processing on ET101 (obviously using only ET101CHA) has the same throughput as a job processing on only ET101CHA. (* inherited from FPSINPUT.EQP_TOOLS)

IS_DURABLE_ASSIGNED

LOAD_SEC

For throughput purposes, we would like the begin event to be logged when the first wafer of the lot enters the tool so that we can accurately track theoretical cycle time (TCT) which starts at this point. If the tool logs as desired then this column will be 0 and it usually is. But some tools do not log the begin event until some amount of time later, for example after the pumping time. This column exists to account for this delay and it is the number of seconds from when the first wafer enters until the begin is logged. We simply add this time to the processing time to get the TCT. This is by eqp_type as we estimate that all recipes of all tools in the same eqp_type will be consistent in this behavior. Please note that unload_sec is similar for any time after the end event until the lot can be unloaded. (* inherited from FPSINPUT.EQP_TYPES)

UNLOAD_SEC

Seconds after the end is logged until the lot is available to be unloaded. This will often be 0. Unload_sec is added to the first_wafer_sec in throughput calculations. (* inherited from FPSINPUT.EQP_TYPES)

FIXED_CARRIER_SEC

Seconds between units in two different carriers in additional to the normal unit interval. This time is added to the EET, MPU, and UPH. (* inherited from FPSINPUT.EQP_TYPES)

EXP_CASCADE_QTY

Expected number of wafers in a cascade is only for cascading tools which are not batch tools. It is used in throughput calculations to determine how many unit_intervals to count after each first_unit_sec. If this is not populated we use the exp_qty_per_carr_for_wph as the default meaning we cascade just one carrier. This value could also be used in dispatching/scheduling to specify how many wafers should be cascaded before a setup change is allowed. Historical data should be compared to this value regularly to verify it. (* inherited from FPSINPUT.EQP_TYPES)

EXP_CASCADE_BATCHES

Expected cascade batches is only for cascading batch tools. It is used in throughput calculations to determine how many batch_intervals to count after each first_unit_sec. If this is not populated we assume the batch tool does not cascade. This value could also be used in dispatching/scheduling to specify how many batches should be cascaded before a setup change is allowed. Historical data should be compared to this value regularly to verify it. (* inherited from FPSINPUT.EQP_TYPES)

EXP_QTY_PER_JOB

If populated this value is used for the EET/TCT calculation for this eqp type instead of avg_qty_per_carr_for_wph which is the default for the facility. (* inherited from FPSINPUT.EQP_TYPES)

MAX_QTY_IN_JOB

Normally we assume that the maximum qty in a job for a non-batch tool is the max_qty_per_carrier for the facility. However sometimes the maximum per job is less than that and this column allows us to override. For example, the max_qty_per_carrier for the facility is 25 but a certain eqp type can do no more than 13 units per job. In this case, if the carrier has 13 wafers or less then we schedule normally but if it has more than 13 then we must ask for a split. (* inherited from FPSINPUT.EQP_TYPES)

WAFERS_PER_DISC

This number is specifically used to calculate throughput on tools that run per disc rather than per unit or per batch. It is most commonly set to 13 or 17 for Implant tools. It must be set along with CAN_MULTIPLE_LOTS_SHARE_DISC. (* inherited from FPSINPUT.EQP_TYPES)

CAN_MULTIPLE_JOBS_SHARE_DISC

For tools that run per disc, we need to know if a disc can combine wafers from multiple jobs (job is usually lot). If N, this means we can divide job qty by wafers per disc to get number of discs used for the lot. For the common case of 25 wafers per carrier and 13 wafers per disc then any lot with 1-13 wafers will use 1 disc and 14-25 wafers will use 2. If Y, it is more complicated. In the same common case, the first lot will use two discs 13+12 then a second cascading lot of the same recipe will use three discs 1+13+11 then third also three discs 2+13+10 and so on. This must be set along with WAFERS_PER_DISC. (* inherited from FPSINPUT.EQP_TYPES)

IS_BATCH_THP

This is a critical value for throughput calculations. Throughput for batch tools is the same regardless of the qty in the batch. Throughput for non-batch tools varies based on the qty in the job. Usually this is Y when max_batch_size_carriers > 1 but not always. We can have tools who load multiple carriers together but whose throughput is calculated per unit. We can also have tools who load only single carriers but whose throughput is calculated per batch. (* inherited from FPSINPUT.EQP_TYPES)

INHIBIT_E_FOR_SCH

In the curr_rank logic used for ETP, perm_rank E (Emergency) automatically becomes U (Use Emergency) when all other allowed tools are down or blocked. The idea of this logic is that we will only want to run lots of rank E when there is no better available allowed tool. When this column is set to Y then we replicate this behavior for Scheduler and only send lots with perm_rank E to the Scheduler when all other allowed tools are down or blocked. If this is set to Y and the lot has at least one other tool of a better rank like P or A then we will not show this tool as an option for this lot on Scheduler. (* inherited from FPSINPUT.EQP_TYPES)

SCH_USE_TOOL_THP_ESTIMATES

This column has a default value of Y but by setting this to N you can configure the Scheduler to not use tool-specific throughput estimates. The use case is when you know that one tool in the eqp_type has been faster than another tool in recent weeks but we do not want the faster tool to get any preference in Scheduler. Technically speaking, when this flag is set then calls to GET_THP_VALUES from Scheduler objects will not lookup estimated values in THP_TOOL_AUTO but will get all estimated values by eqp_type from THP_EQPTYPE_AUTO. This flag does not apply to lots which have already started processing on the tool and have an actual_machine_recipe since at this point the tool is already chosen and getting the most accurate data is more important than avoiding preferring one tool over another. In addition to one tool actually processing lots faster, please note that faster throughput estimates can also be caused by loading one tool significantly more efficiently than another tool and therefore cascading better. This is because our throughput estimates attempt to estimate the throughput on a perfectly cascading tool but the only reasonable way to define "perfect cascading" is to use the best cascading that we observed on the tool from the history. (* inherited from FPSINPUT.EQP_TYPES)

SCH_INHIBIT_SEC_FOR_DOWN

Used for Scheduler. This flag prevents lots from scheduling to down entities if the expected downtime of the entity is equal to or longer than this flag. This flag should be null if you never want to inhibit lots from scheduling (this is the default). Setting to 0 will always inhibit lots from scheduling to down entities (* inherited from FPSINPUT.EQP_TYPES)

NUM_TOOLS_IN_PF

RQD_SETUP

Rqd_setup is determined by ovr_rqd_setup in RTG_TOOL_ASSIGNMENTS and use_process_as_rqd_setup and use_est_mach_rcp_as_rqd_setup from EQP_TYPES. The latter two columns allow us to easily specify for an eqp_type that setup times should be calculated by process or est_machine_recipe. For traditional setups that are a group of recipes we use ovr_rqd_setup. (* inherited from FPSBASE.WIP_LOT_HIST)

RCP_EXP_QTY_PER_BATCH

RCP_MAX_MERGE_NUM_LOTS

RCP_MAX_BATCH_SIZE_CARRIERS

RCP_MAX_BATCH_SIZE_LOTS

RCP_MAX_BATCH_SIZE_UNITS

RCP_MIN_BATCH_SIZE_CARRIERS

RCP_MIN_BATCH_SIZE_LOTS

RCP_MIN_BATCH_SIZE_UNITS

RCP_MIN_BATCH_WAIT_MINS

RCP_LABOR_ROLE

RCP_LABOR_SEC_PER_BATCH

RCP_LABOR_SEC_PER_CARR

RCP_LABOR_SEC_PER_UNIT