FPSBASE.WIP_STEP_FUT_ASGN_FOR_SCH

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)

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

EFF_RANK

EFF_RANK_DISPLAY

EFF_RANK_SORT

CH_RANK_AND_REASON

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)

PERM_PROC_STATE_IF_WAIT

PERM_RANK_DISPLAY

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)

TEMP_PROC_STATE_IF_WAIT

TEMP_RANK_DISPLAY

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)

EXTL_PROC_STATE_IF_WAIT

EXTL_RANK_DISPLAY

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_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)

LONGEST_CH_PATH

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)

TOOL_FOR_TTS

TTS for tool is greatest(last start plus EET of last start, data_date). TTS for first lot not started is the same as the TTS for tool but we need to store TTS for tool because tool might not have any reserved lots. TTS for subsequent lots cums the EET of each lot after the first lot. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

WEH_RESERVE_TOOL

MANL_RESERVE_TOOL

Stores tool reserved by NextMove (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

EXTL_RESERVE_TOOL

SCHED_TOOL

the tool from the first lot that scheduled (* inherited from FPSAPP.SCH_W_SCHED_DURABLE_INSPECT)

MANL_RESERVE_USERNAME

EXTL_RESERVE_USERNAME

EXTL_IS_RESERVED

Flag indicated whether the external system has reserved the lot to the tool. If not we still move to the destination. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

SCHED_IS_RESERVED

WEH_RESERVE_QTY_IN_JOB

MANL_RESERVE_QTY_IN_JOB

EXTL_RESERVE_QTY_IN_JOB

SCHED_QTY_IN_JOB

WEH_RESERVE_ACTUAL_MACH_RCP

SCHED_RECIPE

SCHED_DURABLE

SCHED_DURABLE_THP_VARIATION

WEH_RESERVE_ACTUAL_CH_USED

MANL_RESERVE_CH_TO_USE

List of chambers to use for processing set by NextMove when lot is reserved. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

EXTL_RESERVE_CH_TO_USE

SCHED_CH_TO_USE

Please note that the Scheduler often populates this with M which indicates the main tool therefore we often should filter out a value of M when using this value since that it not a valid chamber combination. When this is populated with any value other than M then we use this as est_ch_used rather than calculating with GET_CH_ALLOWED_STATUS or GET_CH_PATH_STATUS. (* inherited from FPSBASE.WIP_STEP_FUTURE_SCHED)

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)

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)

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)

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)

NUM_TOOLS_IN_PF

IS_PORT_GROUP_UP

IS_PORT_GROUP_AUTO

PORT_MODE_FOR_GROUP

IS_PORT_UP

IS_PORT_AUTO

PORT_MODE

PORT_MODE is the port equivalent to EQP_STATE. Examples might be AUTOMATIC, MANUAL, SEMI-AUTOMATIC, or DOWN. If configured in GEN_FACILITIES, the view DASH_P_TOOL_PORTS can overlay whether the port is occupied along with its carrier and the WIP processing states over the port modes as long as the port mode has is_up set to Y. Therefore it is not necessary to reflect occupied or empty when developing the ETL logic to populate the EQP_PORTS table. (* inherited from FPSINPUT.EQP_PORT_MODES)

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

FIRST_UNIT_SEC

Time for one unit to process when the tool starts from a standby state. On a batch tool -- defined as a tool where all units process together and take the same time regardless of qty -- this is the time for the batch. See our complete throughput documentation for more details. (* inherited from FPSINPUT.THP_EXTERNAL)

UNIT_INT_SEC

BATCH_INT_SEC

THP_FILLIN_GROUP

THP_MEMO

QTY_IN_JOB_FOR_THP

NUM_DISCS_FOR_JOB

Number of discs used in the job as estimated by our throughput logic. (* inherited from FPSBASE.WIP_LOT_HIST)

ACTUAL_CH_USED_FOR_THP

EST_CH_USED_FOR_THP

CH_TYPE_CNT_FOR_THP

THP_CH_TYPE_CNT