FPSADMIN.SCH_P_CURR_ENTITIES

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)

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)

MODULE

Modules are departments of people who manage certain areas of the fab. The modules are assigned ownership of a set of tools to operate and maintain as well as steps on the route that they are responsible for executing. Since many of our tables include tool and step information together, we must distinguish between the owner of the step (WIP_MODULE), the owner of the operation of the tool (EQP_MODULE), and the owner of the maintenance of the tool (MNT_MODULE). WIP_MODULE is used to credit moves and set goals. Each route-step is assigned to a process family and then its wip_module is defined by the process family. EQP_MODULE is used to group tools particularly for tool performance reporting. Similar to WIP, each tool is dynamically assigned to a process family based on its assignments and then its eqp_module is defined by the process family. MNT_MODULE is usually the same as EQP_MODULE but unlike EQP_MODULE is not dependent on assignments but only on the EQP hierarchy. Each tool is assigned to an eqp_type and each eqp_type is assigned to a mnt_family and each mnt_family is assigned to a mnt_module. (* inherited from FPSINPUT.GEN_MODULES)

TOOL_TYPE

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

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)

TOOL_SORT

ENTITY

The lowest level of the equipment hierarchy that an event can be logged against. Tools, subtools, shared parent tools, chambers, ports are all entities. Load locks are also included although we consider them as ports. (* inherited from FPSINPUT.EQP_STATUS_VERIFY)

CH_SHORT_DISPLAY

Short display for the chamber displayed on Dashboard and reports as part of a list of chambers used. This should not include the tool name but only the chamber on the tool so if the chambers on ET11 are ET11CHA and ET11CHB1 and ET11CHB2 then this field should be A, B1, and B2. (* inherited from FPSINPUT.EQP_CHAMBERS)

CH

A single character to identify the chamber which must be unique with the tool. We concatenate the CH to get the string for CH_USED so it is helpful for diagnostic purposes if this single character is representative of the chamber (i.e. A for ET12CHA or 1 for MD27C1) because then the CH_USED string makes sense. However it is not required and if the chamber naming is inconsistent we might get use 1, 2, 3, etc. for the CH. (* inherited from FPSINPUT.EQP_CHAMBERS)

CH_TYPE

This column is critical for sequential chamber tools where a wafer goes through multiple chambers. It identifies the type of chamber so two chambers with the same ch_type are identical and wafers can use either one. See comment on mfg_pct_per_ch column for an example. For independent chamber tools where all chambers are the same and each wafer goes to only one chamber then ch_type should be set to the default value CH so that ch_type_cnt is 1CH, 2CH, 3CH, etc. (* inherited from FPSINPUT.EQP_CHAMBERS)

BAY

A bay is a physical area within the building. The bay is important for estimating travel time for a carrier to reach its destination as we usually store these estimates as a matrix of bay-to-bay and assume that the estimated time from any location within one bay to any location within another bay is approximately the same. (* inherited from FPSINPUT.MHS_BAYS)

AVAILABILITY

SHOULD_SCHEDULE

Indicates if it should force scheduler to schedule this step or not. Setting this value to Y also forces a TAKE decision for this step in WIP_STEP_FUTURE. (* inherited from FPSINPUT.WIP_STEP_FUTURE_OVR)

CURR_SETUP

The current setup of the entity. This can be set by a lot processing event from WIP_EVENT_HIST or by an event on the entity from EQP_EVENT_HIST. For example if an Implant tool processes a Boron lot then the curr_setup will be Boron. Or if an event is logged to the tool that says the setup changed to Boron then the curr_setup will be Boron. Please note that the curr_setup value populated in EQP_EVENT_HIST must match exactly with the rqd_setup value in RTG_TOOL_ASSIGNMENTS in order for the setup penalty logic to apply correctly. (* inherited from FPSINPUT.EQP_EVENT_HIST)

CURR_SETUP_COUNT

CURR_SETUP_INST

This DWH timestamp of the last setup change for this entity (* inherited from FPSAPP.SCH_W_H_S_ENTITIES)

CURR_RECIPE

The current/last used recipe for the scheduler, incorporating the ignore capability from EQP_PROCESS_CHG_TO_IGNORE (* inherited from FPSBASE.ETP_STATUS)

CURR_RECIPE_INST

The beg processing timestamp associated with CURR_RECIPE (* inherited from FPSBASE.ETP_STATUS)

NUM_PORTS

RESERVE_CAPACITY

RESERVE_SEC_IF_DOWN

DEFAULT_PROCESS_SEC

WAIT_SEC_TO_VERIFY_SHORT_DOWN

WAIT_SEC_TO_VERIFY_LONG_DOWN

WAIT_SEC_TO_SCHED

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

WAIT_SEC_TO_RELEASE_DURABLE

BG_COLOR_HTML

TEXT_COLOR_HTML

EQP_STATE

Client equipment state taken directly from their MES or from their existing tool state model. For EQP_MNT_FUTURE, this is the state that we estimate the entity will be in during the maintenance which is often set to a generic PM state if we do not have detailed information. (* inherited from FPSINPUT.EQP_L6_DETAILED_STATES)

EQP_STATE_DISPLAY

Display name for the equipment state which will be displayed on all Dashboards and reports. (* inherited from FPSINPUT.EQP_L6_DETAILED_STATES)

EQP_STATE_CHG_INST

Time when the eqp_state changed for this particular entity. If another entity on the same main tool changes state, eqp_inst will change for all entities on the tool even those whose state does not change. Therefore if eqp_inst is after state_chg_inst that means another entity changed state at eqp_inst but this entity has not changed since state_chg_inst. (* inherited from FPSBASE.ETP_STATUS)

EQP_STATUS_COMMENT

An optional comment on the status of the entity that can be displayed in various application interfaces. (* inherited from FPSINPUT.EQP_STATUS_VERIFY)

DEFAULT_SETUP_CHG_SEC

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

DEFAULT_SETUP_CHG_COST

Default setup change cost. See comments on USE_SETUP_CHG_AUTO_FOR_SCH for details on when this is used. (* inherited from FPSINPUT.EQP_TYPES)

DEFAULT_RECIPE_CHG_SEC

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

DEFAULT_RECIPE_CHG_COST

Default recipe change cost. See comments on USE_SETUP_CHG_AUTO_FOR_SCH for details on when this is used. (* inherited from FPSINPUT.EQP_TYPES)

DEFAULT_DURABLE_CHG_SEC

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

DEFAULT_DURABLE_CHG_COST

Default durable change cost. See comments on USE_SETUP_CHG_AUTO_FOR_SCH for details on when this is used. (* inherited from FPSINPUT.EQP_TYPES)

MAX_WAIT_TIME_PCT

to indicate how much time this priority is willing to wait for the coming lots to batch, this need to work with max_wait_time_extra_lots_rqd; if value is 0, then it means not going to wait at all. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

MAX_WAIT_TIME_EXTRA_LOTS_RQD

to indicate how many more lots this priority is willing to wait to batch, this need to work with max_wait_time_pct; by default, 999 meaning not going to way, but the minimum is 1, additional lot required to wait. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

MAX_BATCH_SIZE_CARRIERS

Maximum number of carriers which can be loaded together in a batch. This column must be populated and is used for ETP and for scheduling to determines whether the tool loads in batches. Non-batch tools will have a value of 1 and batch tools limited by units will be populated according to the comment in max_batch_size_units. This is not used for throughput calculation because we can have tools which load multiple carriers at once but whose throughput is calculated per unit. (* 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)

ONLY_KEEP_POD_IF_1_PORT_AVAIL

used to determine if it will only run the pod switch rule when only 1 port available (* inherited from FPSINPUT.RTG_PROCESS_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)

ENABLE_RESERVATION

HOURS_SINCE_PROC

Hours since the tool was last processing lots. (* inherited from FPSAPP.SCH_W_H_S_ENTITIES)

SORT_ORDER_WITHIN_TOOL